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Dependability 

Modeling 

for Multiprocessors 

Chita R. Das, Jeffrey T. Kreulen, and Matthew J. Thazhuthaveetil 
Pennsylvania State University 

Laxmi N. Bhuyan, Texas A&M University 



In addition to delivering high 
performance, multiprocessors 
must be dependable in the 
presence of faults. This 
tutorial describes modeling 
techniques to assess 
multiprocessor dependability. 


h. s multiprocessors take on more and increasingly critical tasks, 
quick and accurate evaluation of both the performance and the depend¬ 
ability of these parallel architectures becomes essential. However, while 
considerable research efforts have been directed at analyzing multipro¬ 
cessor performance, dependability prediction has received less attention. 

In general, increasing system dependability requires shifting resourc¬ 
es from other design goals, such as high performance. Achieving both 
high computing power and high dependability makes system design 
very complex. However, through modeling, a system designer can assess 
whether a design meets dependability requirements, identify design 
bottlenecks, and select an optimal architecture. 
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Figure 1. An MxN crossbar system. 


Figure 2. An MxNxB multiple-bus multiprocessor. 


Laprie and Coste have formally defined 
dependability as a high-level framework 
that encompasses measures like reliability 
and availability as distinct facets of system 
specification. 1 Based on a system’s char¬ 
acteristics, either reliability or availability 
describes its dependability. For example, 
we can best characterize a nonrepairable 
system by its reliability, and a repairable 
system by its availability. 

System reliability at time t is the proba¬ 
bility that the system is operational during 
the interval (0, t), given that it was opera¬ 
tional at time 0. System availability at time 
t is the probability that the system is oper¬ 
ational at the instant t. Unlike reliability, 
availability evaluation does not require 
continuous system operation during the 
interval (0, t ), since a system can go through 
the fail-repair cycle a number of times in 
this interval. 

We need to define precisely the term 
“operational” as used in the above mea¬ 
sures. A parallel machine can do useful 
work even if some of its components are 
nonfunctional, that is, it could be consid¬ 
ered operational even given certain com¬ 
ponent failures. As we will discuss later, 
researchers have suggested four operational 
modes or models for dependability analy¬ 
sis. Each model defines a specific minimal 
requirement for a system to be considered 
operational. 

Dependability measures do not reflect 
the performance of a multiprocessor sys¬ 


tem, only its operational status. However, 
designers must carefully consider the speed/ 
dependability trade-off to ensure that high¬ 
er speed is not attained at the cost of unac¬ 
ceptable dependability or vice versa. So, 
designers of parallel systems need perfor¬ 
mance-related dependability measures in 
addition to measures of dependability alone. 

The quantitative evaluation of both de¬ 
pendability and performance-related de¬ 
pendability should be an integral part of 
multiprocessor design. While reliability and 
availability modeling are classic problems 
that have been applied to many areas of 
science and engineering, few efficient 
techniques have been devised for evaluat¬ 
ing the dependability of parallel comput¬ 
ers. This lack is mostly due to the complex 
nature of the interconnection networks that 
connect a multiprocessor’s computing re¬ 
sources. Accurately modeling the inter¬ 
connection network is extremely complex 
and can become an NP-complete problem. 
Different interconnection network topolo¬ 
gies can require different modeling tech¬ 
niques, making the modeling of these sys¬ 
tems a challenge. 

This article is a tutorial on dependability 
and performance-related dependability 
models for multiprocessors. We will clas¬ 
sify multiprocessors, explain some funda¬ 
mental dependability modeling concepts, 
examine proposed reliability and avail¬ 
ability models, discuss the status of re¬ 
search efforts on performance-related de¬ 


pendability, and illustrate the models’ ef¬ 
fectiveness with a few numerical exam¬ 
ples. We will also provide a brief survey of 
software packages for dependability com¬ 
putation. 

Multiprocessor 

classification 

We can broadly divide multiprocessors 
into two categories: shared-memory archi¬ 
tectures and distributed-memory architec¬ 
tures. In a shared-memory multiprocessor, 
the processors share a common, global 
memory, whereas each processor in a dis¬ 
tributed-memory multiprocessor has a pri¬ 
vate memory. 

A shared-memory multiprocessor con¬ 
sists of a number of processing elements 
connected to a number of globally addres¬ 
sable memory modules through an inter¬ 
connection network. There are three main 
types of interconnection networks: cross¬ 
bar, multiple-bus, and multistage intercon¬ 
nection networks. 2 

We call a multiprocessor with M pro¬ 
cessing elements and N memory modules 
an MxN system. Figure 1 depicts an MxN 
crossbar architecture with M ■ N crosspoint 
switches providing unique paths from each 
processing element to each memory mod¬ 
ule. The C.mmp multiprocessor is an ex¬ 
ample of a crossbar-based shared-memory 
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Figure 3. A 16x16 multistage interconnection network multiprocessor. 


system. Since there are M ■ N switching 
elements in a crossbar, it is not an appropri¬ 
ate interconnection for building a large 
system. 

Figure 2 shows an MxNxB multiple-bus 
architecture with M processing elements, 
N memory modules, and B buses where 
B < min(M, N). Encore’s Multimax and 
Sequent’s Balance and Symmetry machines 
are examples of parallel processors using a 
single-bus (B = 1) interconnection. Bus- 
based shared-memory systems are more 
attractive to implement than crossbar-based 
systems, but they are suitable only for 
medium-sized systems with a few tens of 
processors. 

A multistage interconnection network 
(MIN) is a cost-effective communication 
structure for large shared-memory organi¬ 
zations. An NxN MIN consists of log a N 
stages of aXa switching elements, where a 
is a small integer (generally 2 or 4). Each 
stage of the network has N/a switches. A 
plethora of MIN topologies have been pro¬ 
posed that are functionally equivalent but 
that differ in their simultaneous intercon¬ 
nection capabilities. Figure 3 shows a 
specific type of MIN called a Butterfly 
network (N = 16 in the figure). Several 
commercial and experimental systems, such 
as the BBN Butterfly, the IBM RP3, and 
the University of Illinois’ Cedar, have been 
developed or are being developed with this 
connection strategy. 

The second type of multiprocessor, the 
distributed-memory architecture, consists 
of a network of computers (nodes), each 
with its own local memory. While inter¬ 
connection topologies, such as rings, trees, 
and meshes, have been proposed for dis¬ 
tributed-memory systems, the commercial 
hypercube machines (N-Cube/10, Intel 
iPSC, and the Connection Machine) have 
received much attention recently. Figure 4 
shows a three-dimensional hypercube ar¬ 
chitecture. 

Preliminary steps 

A model is an abstract representation of 
a system, derived using various assump¬ 
tions about the system and involving three 
steps — definition, parameterization, and 
evaluation. 

Definition. In this first step, the design¬ 
er precisely defines the system and the 
objective of the modeling. The objective 
could be reliability, availability, or perfor¬ 
mance-related reliability or availability. 
The designer should also identify what 


constitutes an “operational” system, usual¬ 
ly described in terms of available connec¬ 
tivity between working components (nodes) 
through the interconnection network. The 
minimum connectivity for an operational 
system could be based on 

• a connection between a specific pair of 
input and output nodes (terminal de¬ 
pendability), 

• connections between a known set of 
input and output nodes (multiterminal 
dependability), 

• connections between a given percent¬ 
age of the nodes in a system (task- 
based dependability), or 

• connections between all the input and 
output nodes (network dependability). 

Parameterization. The designer now 
defines the model’s input and output pa- 



Figure 4. A three-dimensional hyper¬ 
cube. P-M stands for a processor- 
memory pair. 
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rameters. Typical input parameters include 
component types', failure characteristics, 
such as failure distribution, failure rate, 
and coverage (which is the probability that 
a system will reconfigure successfully fol¬ 
lowing a fault); and repair characteristics, 
such as repair time distribution, repair rate, 
and probability of successful repair. 

For mathematical simplicity, most de¬ 
pendability models assume that failure and 
repair distributions are exponential with 
constant rates. (The failure and repair rates 
of a component i are represented by A,,- and 
(l,, respectively.) General distributions are 
used less frequently. However, simulation- 
based evaluation and combinatorial mod¬ 
els can handle other appropriate distribu¬ 
tions. 

A model’s output parameters include 
such measures as reliability, transient or 
steady-state availability, mean time to fail¬ 
ure for nonrepairable systems, mean time 
between failures for repairable systems, 
reliability improvement factor, and perfor¬ 
mance-related dependability measures such 
as expected performance at time t or ac¬ 
cumulated performance over a given time. 

Evaluation. Finally, a designer can 
evaluate a model using either analytical 
techniques or simulation. Analytical tech¬ 
niques are usually quicker and more cost 
effective than simulation. However, ana¬ 
lytical evaluation is generally less credible 
than simulation because of the simplifying 
assumptions used to develop a tractable 
analytical model. Simulation, on the other 
hand, can be conducted to an arbitrary 
level of detail. 

We can divide analytical techniques into 
four categories: reliability block diagrams, 
fault trees, Markov models, and petri nets. 

Reliability block diagrams or reliability 
graphs. This combinatorial technique rep¬ 
resents in a graphical or block diagram 
form the various combinations of working 
components that exhibit successful overall 
system operation. 

Fault trees. Fault tree representation is 
another combinatorial approach and is 
complementary to the reliability block di¬ 
agram method. It represents system failure 
as a tree, where the root event is system 
failure, and it enumerates the different 
conditions that lead to failure. Reliability 
block diagrams and fault trees are equiva¬ 
lent in their representational power, and 
both are used for reliability analysis. Un¬ 
fortunately, neither can model transient 
faults and on-line repair. 


Markov models. Markov modeling is 
probably the most powerful technique for 
dependability analysis, since it can capture 
issues like on-line repair and transient faults 
in addition to the modeling capabilities of 
other techniques. A system’s behavior is 
modeled as a finite-state continuous-time 
Markov chain, where each state represents 
a unique system configuration (which can 
be a working or failed state). A Markov 
chain can be cyclic or acyclic, depending 
on whether the system is repairable or not. 
A Markov model with n states is expressed 
with a set of n equations. Time-dependent 
(transient) system behavior can be obtained 
by solving n first-order differential equa¬ 
tions, and steady-state behavior can be 
obtained by solving n linear equations. A 
summation of the working state probabili¬ 
ties yields reliability or availability. A 
number of software packages 3 (discussed 
later) use this technique to determine de¬ 
pendability. 

Petri nets. This graphical approach rep¬ 
resents the system as a directed graph. A 
system’s stochastic nature is included in 
the model with timed transitions. The graph 
is then either solved using simulation or 
converted to a Markov model and solved 
numerically. 

For multiprocessors, dependability 
modeling has centered around the two 
combinatorial techniques and Markov 
models. Petri nets have not been widely 
used due to the complexity of generating 
the graphical representation. 


Reliability models 

The four types of reliability evaluation 
techniques are terminal, multiterminal, task- 
based, and network reliability. Most de¬ 
pendability work has focused on crossbar, 
multiple-bus, MIN, and hypercube archi¬ 
tectures, so we discuss each of these four 
multiprocessor types under each of the 
four reliability models. 

Analytical models usually employ some 
simplifying assumptions to keep the anal¬ 
ysis tractable. A common (and usually val¬ 
id) assumption in dependability modeling 
is that components fail independently of 
each other, since each component is a 
separate entity. Another frequent assump¬ 
tion, exponentially distributed time to 
failure, facilitates system modeling. 

Terminal reliability. The most basic 
reliability analysis is terminal reliability, 
the probability that at least one path exists 


between two specific terminals. Failure 
occurs when a terminal fails or when no 
path exists between the two terminals. 

A terminal can be any of a range of 
entities. For example, each terminal could 
be a processor-memory pair, in which case 
terminal reliability could determine the 
reliability of two communicating process¬ 
es. Alternatively, one terminal could be a 
processor and the other a memory module. 
Terminal reliability is more appropriate 
for communication networks than for par¬ 
allel architectures, but it can be used for 
multiprocessors in which the source and 
destination nodes are uniquely defined. 

To evaluate terminal reliability, we first 
assess the reliability of the individual com¬ 
ponents and enumerate their relative con¬ 
nectivity. Link failure between nodes is 
typically ignored here to simplify analysis. 
We can ascribe link failure to switch or 
node failure without losing generality. Also, 
since links are passive elements, their failure 
rate is almost negligible. 

Crossbar systems. Consider the MxN 
crossbar system in Figure 1, where pro¬ 
cessing element PE, requests connection to 
memory module MMj. The hardware switch 
organization requires only a single cross- 
point switch to connect an individual pro¬ 
cessor to an individual memory. Hence, to 
connect PE) to MM p only the circled switch 
needs to be operational. Denoting switch 
reliability as R sw (t), terminal reliability is 

TR(t) = R„(t)R m (t)R sw (t) 

where R p (t) and R m (t) are processor and 
memory reliability, respectively. For ex¬ 
ponential distribution with failure rates X p 
and \ m , R p (t) = «rV and R m (t) = e~ Xm ‘. 
Similarly, R sw (t) = e~ Xsw ‘. 

Bus-based systems. The bus-based sys¬ 
tem in Figure 2 has B alternate paths be¬ 
tween any processor-memory pair, allow¬ 
ing communication between any processing 
element and any memory module as long 
as one bus is available. If a system has B 
buses, and the reliability of each bus is 
R b (t) = e~ Xh ‘, then 

TR(t) = R p (t) ■ R m (t) • [1 - (1 - R b (t)) B ] 

The last term is the probability that at least 
one bus is operational at time t. 

MIN systems. There are two kinds of 
MINs: unique path and multiple path. For 
unique-path MINs, terminal reliability is 
related to the number of stages in the net¬ 
work. Given a unique-path MIN with n 
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Figure 5. A reliability block diagram representation of various paths between 
node 0 and node 7. 


(equal to log,, N) stages of switching ele¬ 
ments with individual switch reliability 

/UO, 

TR(t) = R p (t) ■ RJt) ■ RZ (f) 

For multiple-path MINs, there could be 
one or more paths connecting a processor 
to a memory, and the paths might not be 
disjoint. We can analyze such a system 
using a reliability block diagram to repre¬ 
sent the system as a “series-parallel” struc¬ 
ture. Consider two system components, for 
example, network switches A and B. If both 
switches are needed for a valid connection, 
then the switches are modeled as a series 
system with reliability expressed as R ser i es (t ) 
= R A (t) ■ Rn(t). If either switch can provide 
a valid connection, then they are in paral¬ 
lel, and RparalUt) = [1 - (1 - R A (t)) • (1 - 
Rg(t))]. This method quickly becomes in¬ 
tractable for larger systems. 

A special issue of IEEE Transactions on 
Reliability contains a good collection of 
terminal reliability models. 4 For example, 
Varma and Raghavendra used terminal re¬ 
liability to compare three classes of multi¬ 
ple-path networks. They obtained the ter¬ 
minal reliability expressions by iteratively 
analyzing reliability block diagrams, tak¬ 
ing advantage of the networks’ regular 
topologies in which all terminal connection 
pairs have the same terminal reliability. 

Hypercube systems. Multiple-path 
complexity makes the analysis of hyper¬ 
cube systems similar to that of MIN systems. 
The best way to analyze an n-cube (2" 
nodes) is to enumerate the paths and present 
them as a reliability block diagram. There 
are n ! nondisjoint alternate paths from each 
source node to each destination node. 

Let’s analyze the terminal reliability 
between nodes 0 and 7 for the eight-node 
hypercube in Figure 4. Figure 5 shows the 
reliability block diagram derived from this 
network. There are six possible nondis¬ 
joint paths from node 0 to node 7. If we 
assume all nodes have the same reliability 
( R„(t ) = Rid) where 0 < i < 7), the terminal 
reliability simplifies to 

TR(t) = 6 ■ R„ 4 (f) - 6 ■ «„ 5 (r) - 3 • R„ 6 (f) + 
6 • «„ 7 (f) - 2 ■ R*d) 

Multiterminal reliability. Multitermi¬ 
nal reliability is a logical extension of ter¬ 
minal reliability. It considers a specific 
subset of terminals instead of a specific 
pair. We define it as the probability that a 
given subset of terminals (nodes) are fully 
connected for simultaneous communica¬ 


tion. This measure has much broader appli¬ 
cation than terminal reliability. For example, 
it can apply to the reliability of tasks on a 
nonreconfigurable system. Multiterminal 
reliability uses many of the same tech¬ 
niques and statistical assumptions as ter¬ 
minal reliability. 

Crossbar systems. An MxN crossbar 
system needs x ■ y operational crosspoint 
switches to connect x processors to y 
memories. This yields the system reliability 

MTR(t) = Rp(t) ■ R£(t) ■ R*„ y (t) 

for 1 < x < M, 1 < y < N. The required 
components are uniquely specified, so the 
status of the other components does not 
affect system reliability. 

Bus-based systems. For an MxNxB bus- 
based system, the contribution of bus reli¬ 
ability is the same as in a terminal reliabil¬ 
ity scheme, since we need at least one bus. 
If a known set of x processors and y 
memories is required for a valid connec¬ 
tion, reliability would be 

MTR(t) = Rj(t) ■ R y {t) • [1 - (1 - fl t (f)) B ] 

MIN systems. The multiterminal reli¬ 
ability of a unique-path MIN system is 
related to s, the number of switches re¬ 
quired for the connection of x processing 
elements to y memory modules. This s 
depends on the location of the required 
processors and memory in the network. 
Once s is known, the multiterminal reli¬ 
ability becomes 


MTR(t) = R*(t) ■ R y (t) ■ R s s w (t) 

Multiterminal reliability analysis of 
multiple-path networks is complicated and 
requires more study. 

Hypercube systems. Grnarov and Gerla 5 
explored multiterminal reliability for dis¬ 
tributed systems by applying a Boolean 
algebra technique. Their technique could 
apply to hypercube systems as well. A 
system is represented as a probabilistic 
graph G(N, E), where N and E are the sets 
of nodes and links, respectively. Each 
component i is assigned a reliability. The 
multiterminal reliability algorithm uses an 
n-bit path identifier to represent each path 
between a source and destination, where n 
is the number of components that can fail. 
Hence, selecting n = ^considers only node 
failure, n = E considers only link failure, 
and n = N + E considers both node and link 
failure. 

A bit in the path identifier is 1 if it is 
required for the connection, and x otherwise. 
All path identifiers for the input and output 
connections are then manipulated using 
Boolean algebra to find a final symbolic 
expression, which is converted to probabi¬ 
listic form to determine multiterminal re¬ 
liability. 

Task-based reliability. Reliability 
models based on task requirements are 
more general than terminal or multitermi¬ 
nal reliability, since they do not explicitly 
specify the source and destination nodes. 
A system remains operational as long as a 
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task can be executed with the available 
resources. Therefore, if a task needs at 
least I processing elements and J memory 
modules in a shared-memory environment, 
or I nodes in a distributed-memory envi¬ 
ronment, the system is considered opera¬ 
tional as long as those resources are avail¬ 
able. Task-based reliability thus lets us 
improve fault tolerance by incorporating 
“graceful degradation” in the system. 

Crossbar systems. Ingle and Siewiorek 6 
used a combinatorial technique to find the 
C.mmp architecture’s task-based reliabili¬ 
ty. Let’s represent the probability that i out 
of x components are working at time t as 

,c,( t) = (f)R‘(t ) • (i - my-‘ ■ C*-' 

where R(t) is the component’s reliability 
and C is the associated coverage factor. 
Using this notation, we express the MxN 
crossbar reliability that needs at least I 
processing elements and J memory mod- 

TBR(t) = X Z MCi(t) ‘ NC J (t) • R ^baAt) 

i=I i= J ( 1 ) 

where M = N = 16 for C.mmp. R x .b a M is 
the reliability of the complete 16x16 
crossbar switch used in C.mmp. The two 
summations generate all possible proces¬ 
sor-memory combinations. 

This model does not consider crossbar 
degradation. We can formulate an approx¬ 
imate model for capturing crossbar degra¬ 
dation as follows. Assume we need a con¬ 
nected group of i processing elements and 
j memory modules in an MxN crossbar 
system. Since one switch is needed to con¬ 
nect each processing element to each mem¬ 
ory module, we need i ■ j switching ele¬ 
ments for the required connection. Lety = i 
■ j, and let the unused switches M ■ N-y = 
e. There are two ways an MxN crossbar 
system could provide the ixj required 
connection: 

• when exactly i processing elements and 
j memory modules are functional, and the 
required y switching elements are avail¬ 
able to provide the needed connections 
(let’s denote this probability as P,- j (1) (f), 
where (1) represents this first case); or 

• when more than i processing elements 
or j memory modules are functional, but 
only y switching elements are available to 
make the ixj connection—let’s denote this 
probability as P, j( 2)(t). 

We could write P t as 


P w ff) = If CKO ■ N Cj{t) ■ R 1(f) (2a) 

Note that the condition of the extra switch¬ 
ing elements e is irrelevant when switch 
coverage is perfect. We can easily include 
imperfect coverage of switching elements 
in Equation 2a. 

We can approximate the second term 
Pi.m(t) as 

■ R'Ut) ■ (1 -R sw (t)f (2b) 

where x > i or y > j. In this equation, (1 - 
R s J.t)Y denotes the probability that the 
extra switching elements have failed, so 
that there is only a connected group of ixj. 

We can then combine these two terms to 
define TBR(t) as 

TBR(t) = f j f j (P m fi) + P iJ(2 fi)) 

i=/ j=J (2c) 

Bus-based systems. In a bus-based sys¬ 
tem (as in Figure 2), all computing resourc¬ 
es are connected to the buses. Analysis is 
simple because there is a path between any 
processing element and memory module 
as long as there is at least one operational 
bus. The bus structure’s contribution to 
system reliability is 1 - (1 -R b (t)) B . Sub¬ 
stituting this term for R x . bil f(t) in Equation 
1 gives us the multiple-bus reliability. 

MIN systems. Task-based reliability 
analysis for MIN multiprocessors is ex¬ 
tremely difficult, mainly because of the 
complexity of the MIN. A detailed single- 
level Markov model of the complete sys¬ 
tem (including processing elements, mem¬ 
ory modules, and switching elements) is 
almost impossible to construct due to the 
large number of states. Therefore, other 
techniques such as simulation and system 
decomposition have been used for task- 
based reliability analysis. 

We have developed a simulation model 
for analyzing the task-based reliability of 
MIN multiprocessors. It considers the fail¬ 
ure of processors, memory, and switching 
elements. The model can compute the task- 
based reliability of different types of unique- 
path and multiple-path MINs and could be 
used to validate analytical models. A 
drawback of this approach is that the sim¬ 
ulation is expensive for large systems. 
However, we doubt that accurate analyti¬ 
cal techniques can be developed for ana¬ 
lyzing the task-based reliability of multi¬ 
ple-path systems. 


Hierarchical decomposition can be used 
to analyze MIN systems. This scheme, 
which decomposes a larger system into 
smaller subsystems for ease of analysis, 
has been applied to the task-based reliabil¬ 
ity modeling of a Butterfly network-based 
multiprocessor. The Butterfly network uses 
4x4 crossbar switches, as shown in Figure 
3. The number of system nodes is 4", and 
each node consists of a processing element 
and a memory module. We call this a 4"x4" 
multiprocessor. We can partition a 4"x4" 
configuration into four 4' !-l x4" -1 sub¬ 
systems without disturbing the connections. 
Therefore, the reliability of a 4" multipro¬ 
cessor depends on four4 n ~' subsystems and 
the connection pattern between them. The 
analysis starts with the probability expres¬ 
sions for a configuration of four processing 
elements, four memory modules, and two 
switching elements. 

Let P 4(ii y)(f) be the probability that i 
processing elements and j memory mod¬ 
ules (0 < ij < 4) are working at time t. We 
obtain this using simple combinatorics. 
The 4x4 analysis is used to find the proba¬ 
bility that I processing elements and J 
memory modules are working in a 16x16 
multiprocessor. We express this using four 
groups of 4x4 subsystems as 

Fi6 ( /, = Pm o. ,„>« ■ p «t\. A)W ■ 

P^n.niD' P«n,«)(» 

such that (i'o + i\ + h + h) = I and (j 0 + j t + 
j 2 + j 2 )=J. All possible combinations of the 
I processing elements and J memory 
modules are generated for the above ex¬ 
pression. Finally, the reliability of the 16- 
node system with at least I processing el¬ 
ements and J memory modules working is 

TBR (t) = ft PWJ)(0 (3) 

;=/ j=J 

We can obtain the reliability of a 64- 
node system from four 16-node configura¬ 
tions using the above technique. A 64-node 
Butterfly has three stages with 16 switch¬ 
ing elements per stage. The first- and last- 
stage switching elements are included in 
the basic 4x4 analysis. Therefore, we can 
determine the required number of middle- 
stage switching elements for any working 
group by using an approximate calculation. 
The reliability of these switching elements 
is multiplied with the / > 64(i,;)(0 expression 
to guarantee that the middle-stage switch¬ 
ing elements provide the required ixj con¬ 
nection for the two possible cases discussed 
in the earlier crossbar analysis. Similarly, 
we can compute the reliability of a 256- 
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node Butterfly multiprocessor using the 
results of four 64-node subsystems. 

Hypercube systems. Kim et al. have pro¬ 
posed a task-based reliability model for 
hypercube architectures. 4 Their model, 
which finds the probability that an n-cube 
has at least I connected working nodes, is 
based on a decomposition technique and 
can handle any amount of system degrada¬ 
tion. Since an n-cube can be divided into 
two (n-l)-cubes, this scheme recursively 
decomposes a large cube into smaller cubes 
until it is simple enough to model. The 
smallest cube is called the “base model” of 
the analysis. A 2-cube (four nodes) or a 3- 
cube (eight nodes) can be the base model, 
since in both cases it is simple to find exact 
expressions for / connected nodes. We can 
then recursively obtain the reliability of 
higher dimension cubes from either base 
model by approximating the connectivity 
between two lower dimension subcubes. 

For example, to calculate the probability 
of j connected nodes in an n-cube, we di¬ 
vide the n-cube into two (n-1 )-cubes. There 
are two cases in which an n-cube will have 
j connected nodes. In the first, exactly j 
connected nodes are working in the n-cube. 
In the second, more than j nodes (say x) are 
working, but the actual connectivity is only 
j. We can divide the j or x working nodes 
between the two (n-l)-cubes as k and j-k 
or x - k. Five working node distributions 
are then analyzed from these two cases to 
find the probability of j connected 
nodes from the two (n-1 )-cubes. The n-cube 
reliability is 

TBR (t) = Pj (t) (4) 

This approach could be extended to find 
a subcube of dimension m, for m < n, in an 
n-cube, based on the assumption that a job 
needs a cubic allocation instead of simply 
/ connected nodes. 

Network reliability. Network reliabili¬ 
ty is the probability of maintaining a full- 
access network. If we consider only unique- 
path networks, network reliability is the 
probability that all system processors and 
memories are connected (no degradation 
of the computing elements is allowed). A 
network with multiple communication paths 
(as in a multiple-bus architecture) can have 
full access even if network components 
fail. 

Determining network reliability for 
crossbar, multiple-bus, and unique-path 
MIN architectures is trivial. All the M ■ N 


switches inacrossbar and all theN/a log„ N 
switches in a MIN must work to connect 
any input and any output. In a multiple-bus 
system, a path exists as long as at least one 
bus is working. 

However, the analysis of multiple-path 
MINs is extremely difficult. Blake and 
Trivedi 4 have provided a bounding analy¬ 
sis for multiple-path MINs using a reliabil¬ 
ity block diagram approach. In this ap¬ 
proach, the number of switching elements 
required for full connectivity is represented 
as one path (subsystem). The number of 
such paths is the same as the number of 
disjoint paths between the system’s input 
and output nodes. We can than compute the 
MIN’s reliability and mean time to failure 
using the standard reliability block diagram 
solution technique. 

Network reliability is a special case of 
task-based reliability where the system does 
not allow the degradation of computing 
resources. We can use the task-based reli¬ 
ability models discussed above to deter¬ 
mine network reliability. 

Availability models 

Reliability prediction gives us a pessi¬ 
mistic view of a system, since it does not 
consider repair activities. In gracefully 
degrading systems, for example, the repair 
of failed components increases the sys¬ 
tem’s operational life and provides higher 
system availability. 

Evaluating the availability of a complex 
system with a single (limited) repair facil¬ 
ity is more complex than reliability mod¬ 
eling. This complexity is attributable to 
two factors. First, we must generate a 
system’s Markov chain to analyze its 
availability. This process can be quite 
complex for a large system. The number of 
states in the model can also be too large to 
handle easily. Second, finding a closed- 
form solution for transient or steady-state 
availability is extremely difficult. There¬ 
fore, numerical techniques are used to 
compute availability. 

There has been little research on analyz¬ 
ing multiprocessor availability. Research 
has focused mainly on task-based avail¬ 
ability, typically based on the assumption 
that each type of component has a separate 
repair facility with an exponential distribu¬ 
tion of repair time. 

Crossbar systems. Smith and Trivedi 7 
developed a Markov chain for a 16x16 
crossbar system (C.mmp) where the entire 
crossbar switch is treated as a single ele¬ 


ment. This model is simple, since the cross¬ 
bar failure results in system failure. The 
model is a two-dimensional Markov chain, 
one dimension representing processing el¬ 
ement failure and the second representing 
memory module failure. The Markov chain 
could include separate repair of processing 
elements and memory modules and could 
then be solved with a software package. 

Bus-based systems. Das and Bhuyan 8 
have modeled a multiple-bus multiproces¬ 
sor as a regular three-dimensional Markov 
chain where each dimension represents the 
degradation of one type of component 
(processor, memory, and bus). Assuming 
that the processors, memory modules, and 
buses each have independent repair facili¬ 
ties, the Markov chain can include the 
repair rates to depict a repairable system. 
The model can then be solved with a soft¬ 
ware package. 

MIN systems. The availability model 
for MIN multiprocessors proposed by Das, 
Tien, and Bhuyan 9 can handle large sys¬ 
tems and any level of degradation. This 
scheme uses a system decomposition ap¬ 
proach to avoid the generation of a detailed 
single-level Markov chain. The model as¬ 
sumes independent failure and repair be¬ 
havior of the processing elements, memo¬ 
ry modules, and switching elements, and it 
conceptually divides the system into three 
subsystems connected in series. We can 
therefore develop independent Markov 
chains for the three subsystems. 

Each subsystem’s Markov diagram is a 
simple one-dimensional chain. For exam¬ 
ple, Figure 6 shows the Markov chain for a 
processor subsystem that needs at least I 
processing elements. X p and p p represent a 
processing element’s failure rate and re¬ 
pair rate, respectively. The system moves 
from a state i to neighboring state i - 1 with 
a failure rate i ■ X p or to state i + 1 with repair 
rate p p . We have omitted the imperfect 
coverage and imprecise repair parameters 
for simplicity. The above model could be 
solved with a numerical analysis package 
such as the Hybrid Automated Reliability 
Predictor 3 to find the probability of i working 
processing elements for I < i < N. 

The Markov model for the memory sub¬ 
system is almost identical, except that the 
system tolerates only up to J failures. The 
memory failure and repair rates are X m and 
p m . Solving this model gives Pj(t), the 
probability that there are j working mem¬ 
ory modules at any time t. 

The Markov chain for the switching el¬ 
ements is based on finding the number of 
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switching elements required for an ixj 
connection. Let’s assume we need to com¬ 
pute the probability that eight processing 
elements and eight memory modules are 
connected in the 16x16 system shown in 
Figure 3. We could divide this system into 
four groups, each comprising four pro¬ 
cessing elements and four memory modules. 
We can distribute the eight processing el¬ 
ements and eight memory modules in two, 
three, or four groups. 

There are two cases that could yield an 
8x8 connection. In the first case, exactly 
eight processing elements and eight mem¬ 
ory modules are working and are connected 
through the required number of switching 
elements. The other switching elements do 
not affect the connectivity. For example, if 
the working components are distributed in 
two groups, four switching elements must 
work for the connection to be valid. These 
switching elements belong to the two 
working groups and can be separated from 
the other four switching elements. The 
connectivity is 8x8 regardless of whether 
the other four switching elements work. 
The Markov chain in Figure 7 shows this 
case, with X SE and p. 5£ representing the 
switching elements’ failure and repair rates. 

In Figure 7, ( x , y) represents the required 
switching elements ( x ) and extra switching 
elements (y), such that x + y is the total 
number of switching elements in the MIN. 
The horizontal transitions show that the 
system fails (state F h where 0 < i <y) when 
any of the x required switching elements 
fails. The vertical transitions show the fail¬ 
ure and repair of the extra y switching el¬ 
ements. Consequently, MIN reliability is 
I.j =0 P X J {t). Let’s denote this as P S £ ( i)(0, 
where (1) indicates the first case, that is, 
exactly i processing elements and j mem¬ 
ory modules are working. For Figure 7, 
with x=y = 4, P SE (i)(0 = (P 4 , 4« + P 4 , 3» 
+ p 4,2(0 + i(0 + P 4 , o(0>. The exact ixj 

connection probability for the crossbar is 
Pi.jO)W = P ;W ' P yW ' PsE(])(t)- 


In the second case, more than i processing 
elements (say a) or more than j memory 
modules (say P) can work while actual 
connectivity remains ixj. For example, more 
than eight processing elements and eight 
memory modules can work in Figure 3, 
with connectivity remaining 8x8 as long as 
only the switching elements required for 
eight processing elements and eight mem¬ 
ory. modules are working. If the 8x8 con¬ 
nection is distributed in two groups, we 
need four switching elements. The other 
four switching elements should fail (mak¬ 
ing y = 0) so that the extra processing 
elements and memory modules in the rest 
of the system do not contribute to avail¬ 
ability. Hence, P SE ( 2 )(t) = P Xt 0 (0 is the 
probability that only x switching elements 
are working. We obtain the second-case 
probability P iJ{ 2 >(f) by multiplying P x 0 (f) 
by the probabilities that a processing el¬ 
ements are working and that p memory 
modules are working, given as P a (t) and 
Pp(t). We get the values for P a (t) and Pp(t) 
by solving the processor and memory 
Markov chains. We then determine system 
availability by adding all the working con¬ 
figuration probabilities using Equation 2c. 
We can apply this same approach to larger 
systems. 

Hypercube systems. Das and Kim 10 have 
developed an availability model for hyper¬ 
cube computers with a single repair facili¬ 
ty. It computes the transient and steady- 
state availability of hypercubes of any size. 
This approach does not require the gener¬ 
ation of a hypercube’s detailed Markov 
chain. 

The model first computes the probabili¬ 
ty that any x nodes (x<N= 2") in an n-cube 
are working (irrespective of their connec¬ 
tion). This problem reduces to a machine 
repairman model (with or without imper¬ 
fect coverage and imprecise repair) with N 
nodes. We can then easily compute the 
probability of a state x at any time t using 



Figure 7. A Markov chain representa¬ 
tion of a multistage interconnection 
network. 


any standard availability package. 3 Multi¬ 
plying this probability by a connection 
probability yields the probability that j out 
of x working nodes are connected in a 
hypercube. The connection probability is 
computed using an approximation tech¬ 
nique. A recursive equation is derived to 
compute this connection probability of an 
n-cube from a 2-cube base model. 

We can explain the technique with an 
example of a 2-cube system. Figure 8a 
shows the Markov chain of a hypercube 
with no failure rate X and no repair rate p. 
We again assume that the coverage and 
repair processes are perfect. There are two 
possible states when two nodes are work¬ 
ing. The first is state 2, in which both 
working nodes are connected. The second 
is state 1:1, where the two nodes are dis¬ 
connected. This is possible when the diag¬ 
onal nodes of a 2-cube are working. We 
can solve this Markov chain by using a 
package like the Hybrid Automated Reli¬ 
ability Predictor 3 to find the probability of 
any state j. An alternate approach is to 
compute this probability from the machine 
repairman model. 10 

If topological connectivity is neglected, 
the Markov chain of the system with N 
nodes is given by a machine repairman 
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model. As shown in Figure 8b, the model 
assumes the system is fully connected with 
N nodes and a single repairman. Let P xc (t) 
represent the probability of x working nodes 
at time t. The c indicates a fully connected 
system (it does not consider hypercube 
connectivity). If we analyze both Figure 8a 
and 8b, we can see that state 2 in Figure 8b 
represents a situation where two nodes are 
working in the system. In Figure 8a, the 
same two working nodes give two distinct 
states (2, 1:1) due to topological connec- 

There is a fixed probability with which 
two working nodes in the 2-cube can be in 
state 2 or in state 1:1, respectively. For 
example, the probability that the two nodes 
will be connected (in state 2) is 2/3; the 
probability that they will be disconnected 
(in state 1:1) is 1/3. Let’s call these proba¬ 
bilities “connection probabilities.” Let’s 
also call the term P xc (t) the “total proba¬ 
bility” of x working nodes, disregarding 
the connectivity. Hence, if the total proba¬ 
bility P 2( .(r) of state 2 in Figure 8b is mul¬ 
tiplied by the connection probability 
2/3, we get P 2 (0 for state 2 in Figure 8a. 
Similarly, Pi c (t) ■ 1/3 gives the probability 
of state 1:1. A general expression of this 
idea for an n-cube is 

2" 

Pj (0 = ^ P xc (t) • P (connectivity = j) 

The first term is the probability that a set of 
x nodes are working. The second term is 
the connection probability, x is summed 
from j to 2 " because of the ^-connection 
requirement. We can then use Equation 4 
to obtain the task-based availability for an 
system with / connected nodes. 


Performance-related 
dependability models 


A performance-related dependability 
measure combines a system’s performance 
and dependability aspects. This measure 
provides more meaningful information than 
is available from just a performance or a 
dependability model, particularly for 
gracefully degrading systems. 

Such a model involves assigning some 
kind of performance index or reward to a 
system’s various working configurations. 
Using the notation of the continuous-time 
Markov chain model, let’s represent a ge¬ 
neric multiprocessor as a finite-state pro¬ 
cess Z(/), with I > 0 and with state space 0, 
State 0 represents the system’s 



Figure 8. An exact Markov chain of a 2-cube (a); a machine repairman model (b). 


failed state and states 1 through n denote 
working configurations. The Markov chain 
could be cyclic or acyclic depending on 
whether the system is repairable or not. 
Solving this Markov chain would yield a 
column vector P(f) = p ] (t),p 2 (t),... ,p n {t), 
from which we get the probability that the 
system is in different working states at 
time t. For example, p,(t) is the probability 
that the system is in state i at time t. 

Now let’s associate a performance in¬ 
dex/reward rate r, with working state i, for 
1 < i < n. If the system stays in state i for 
some duration x, then the reward accumu¬ 
lated in state i is X ■ r,. The system’s accu¬ 
mulated reward (F(f)) in time t would be 7 

Y(t)= fx(t)dT 
J o 

where x(x) is the multiprocessor’s reward 
rate at time x. In turn, x(x) = rZ(x), where r 
is an associated reward vector. We can 
define r with parameters such as band¬ 
width, instruction execution rate, or other 
relevant performance metrics. 


Performance-related dependability 
studies have produced a number of inter¬ 
esting measures. In one of the first at¬ 
tempts, Beaudry introduced measures such 
as computation reliability and computa¬ 
tion availability for degradable multipro¬ 
cessors. 11 Using the concept of working 
state probability p,(r) and an associated 
reward rate r h Beaudry expresses a sys¬ 
tem’s expected computing power at time t 
as 

E[x(t)\ = Y i p i (t)-r i (5 ) 

Beaudry’s model does not consider any 
specific reward measure or network degra¬ 
dation. 

Das and Bhuyan have introduced a pa¬ 
rameter called bandwidth availability, BA(t), 
for shared-memory multiprocessors. This 
is defined as the expected bandwidth of a 
multiprocessor at instant /. 8 Bandwidth is a 
performance measure for synchronous 
systems, defined as the average number of 
processor-memory pairs connected in a 
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Figure 9. Task-based dependability of a 10-cube allowing 25 percent degradation 
(at least 768 nodes must be connected). Node failure rate X = 0.0002; coverage c = 
0.95 (a fault is detected and the system correctly reconfigures 95 percent of the 
time); repair rate p = 0.1 (repairs are assumed to be perfect). Failure and repair 
rates are per hour. 


cycle. Using a task-based reliability ex¬ 
pression (such as Equation 3) for a shared- 
memory multiprocessor that needs at least 
/ processing elements and J memory 
modules, bandwidth availability is 

M N 

BA(t) = II P u (t) ■ BW U (6) 

where Pij(t) is the probability that the sys¬ 
tem is working with i processing elements 
and j memory modules. BW t j is the band¬ 
width (reward r, in Equation 5) of this ixj 
working configuration. 

We can also calculate the expected accu¬ 
mulated performance at time t, E[Y(tj\, 
which is the total amount of useful work 
(average value) that the multiprocessor can 
perform. We obtain this value by integrat¬ 
ing Equation 5 over the observed time 
frame: 

E[Y(t)] = ^ n -J' P i(X)d% (7) 

Another interesting parameter that has 
received wide attention recently is per- 
formability, introduced by Meyer. 12 Per- 
formability is a probability distribution 
function of accumulative system perfor¬ 
mance. It gives the probability that a sys¬ 
tem will complete a given amount of work 
x in time t. Using the cumulative reward 
function Y(t), performability is 


y<Xt)=P[Y(t)Zx] (8) 

Computing this expression is quite com¬ 
plex. For a system with n working states, 
each state reward distribution involves an 
integration. (Recent articles on perform¬ 
ability contain detailed interpretation of 
this equation and solution methods. 12 ’ 13 ) 

Meyer has worked on various aspects of 
performability since introducing it a de¬ 
cade ago. He uses a numerical technique 
for the time-domain convolution equations 
that predict performability in nonrepair- 
able systems. Recently, he has developed a 
software package called Metasan 3 that 
represents a stochastic system as a petri net 
and determines performability using anal¬ 
ysis or simulation. Other researchers have 
also sought closed-form solutions for dif¬ 
ferent classes of nonrepairable systems in 
an effort to reduce the computational 
complexity of finding the probability dis¬ 
tribution. 

Performability evaluation of multipro¬ 
cessors has been limited because task- 
based dependability models are not well 
developed for some networks and deter¬ 
mining the distribution is complex for a 
system with a large number of states. There 
has been limited research on crossbar, 
multiple-bus, and MIN multiprocessors, 
mainly using bandwidth as the performance 
measure of the system. 


Crossbar systems. Smith and Trivedi 7 
have analyzed the performability of the 
crossbar-based C.mmp multiprocessor us¬ 
ing bandwidth as a performance measure. 
They developed a Markov chain of the 
16x16 system, modeling the entire cross¬ 
bar as a single switch. The distribution is 
obtained numerically by using a double 
Laplace transform on variables x and t in 
Equation 8. 

Grassi, Donatiello, and Iazeolla 13 have 
proposed a closed-form expression for de¬ 
termining the performability distribution 
of nonrepairable systems. They compute 
the bandwidth distribution of a crossbar 
with an ideal (fault-free) network. 

Bus-based systems. The double Laplace 
transform technique has also been used to 
model the bandwidth distribution of an 
MxNxB multiple-bus architecture 7 by as¬ 
sociating each working multiprocessor 
configuration with its bandwidth. For non¬ 
repairable systems, closed-form expres¬ 
sions for bandwidth distribution can be 
derived as suggested by Grassi, Donatiel¬ 
lo, and Iazeolla. 13 

MIN systems. Based on the idea illus¬ 
trated in Equation 6, Blake, Reibman, and 
Trivedi 14 have modeled the expected 
bandwidth (bandwidth availability) of a 
16x16 multiprocessor using an Omega- 
type MIN. Their model finds P, j{l), the 
probability of i processing elements and j 
memory modules working in a MIN. They 
multiply this probability by BW, j, the 
bandwidth of an ixj MIN subsystem. The 
model is restrictive in that it cannot be 
extended to higher order systems, mainly 
due to the difficulty of finding Pij(t) and 
the bandwidth of a randomly truncated 
MIN with i processing elements and j 
memory modules. 

Numerical examples 

The analytical techniques presented 
above can be used to quickly assess one or 
more characteristics during a system’s life 
cycle. They can also be used to compare 
parallel architectures. The following ex¬ 
amples illustrating the models’ usefulness 
are confined to task-based analysis, which 
is the most appropriate measure for multi¬ 
processors. 

Quantifying dependability. The mod¬ 
els can predict each architecture’s reliabil¬ 
ity or availability at a given time t or pre¬ 
dict if the architecture can provide a given 
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dependability x over a specified time inter¬ 
val. Also, analyzing how sensitive system 
dependability is to various component fail¬ 
ure rates can identify system bottlenecks. 14 
Consider a hypercube machine with 1,024 
nodes (10-cube). Figure 9 shows the sys¬ 
tem’s reliability and availability, allowing 
for 25 percent system degradation (7 con¬ 
nected), using the hypercube models de¬ 
scribed above. Note that reliability deteri¬ 
orates, while availability attains a 
steady-state value of 0.91. 

Comparing dependability. We men¬ 
tioned earlier that crossbar and shared-bus 
interconnections, unlike MINs, are not 
suitable for large multiprocessors. There¬ 
fore, any dependability comparisons among 
multiprocessors using these three types of 
interconnections should be restricted to 
small systems. 

Consider the design of a 16x16 multi¬ 
processor. Crossbar, shared-bus, and MIN 
approaches are all feasible and must be 
considered. Figure 10 shows the system 
reliability for these three types of systems, 
assuming they have the same total network 
complexity (that is, the same failure rate). 
All three systems operate with approxi¬ 
mately the same reliability when degrada¬ 
tion is not allowed (7 = J = 16). However, 
they have distinctly different reliabilities if 
we allow for 25 percent degradation (7 = 7 
= 12). The shared-bus system performs 
best because it has more alternate paths 
(eight) than the other designs. The reliability 
difference between crossbar and MIN sys¬ 
tems becomes particularly noticeable when 
there is system degradation, due to their 
differing connection capabilities. A switch 
failure in a Butterfly network disconnects 
four processor-memory pairs, whereas in a 
crossbar only one pair is disconnected per 
failure. On the other hand, a MIN’s total 
network complexity is less, since it has 
fewer switches. Thus, we can improve a 
MIN’s reliability by adding extra stages of 
switches. 



Figure 10. Reliability comparison of 16x16 crossbar, 16x16x8 multiple-bus, and 
16x16 Butterfly (MIN) configurations. Processor failure rate X p = 0.0001; memo¬ 
ry failure rate X m = 0.0001; crossbar switch failure rate X SE = 0.000000625; bus 
failure rate X b = 0.00002; MIN 4x4 switch failure rate X SE = 0.00002. 
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Figure 11. Bandwidth availability comparison of 16x16 crossbar and 16x16x8 
multiple-bus architectures. The curves show performance under two different 
task-based requirements, 7 = J = 16 and 7 = J = 12 (allowing 25 percent degrada¬ 
tion). Failure rates: X p = X m = 0.0001; X SE(crosshar) = 0.000000625; X bus = 0.00002; 
coverage c = 1.0. 


Quantifying performance-related de¬ 
pendability. Because system performance 
gradually degrades due to component fail¬ 
ure, we must be able to quantify the expected 
computing power (performance) of a sys¬ 
tem at any time t. We can do this by re¬ 
placing the performance index r, in Equa¬ 
tion 5 with a suitable measure. 

Suppose we are interested in measuring 
bandwidth variation of an MxN synchronous 
crossbar system. For a uniform-reference 
model (that is, each processor is equally 
likely to access each memory), the band¬ 


width is BW mn = N • (1 - (1 - 1 /N) M ). 2 We 
can then use the bandwidth-availability 
expression (Equation 6) to compute the 
expected bandwidth by replacing Pjj(t) with 
its equivalent from the crossbar state prob¬ 


ability expression (Equation 2c) and re¬ 
placing 5IV, j with the crossbar bandwidth 
just defined. We can find BA(t) for a mul¬ 
tiple-bus system in a similar manner. Fig¬ 
ure 11 shows the bandwidth availability of 
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P[Y(t)/t>x] 



Figure 12. Performability (bandwidth) distribution of a 16x16 crossbar. 7 Failure 
rates: X p = 0.0000689; X m = 0.0002241; X crosshar = 0.0002034; coverage c = 1.0. 


a 16x16 crossbar and a 16x16x8 multiple- 
bus system. Although the multiple-bus 
system initially has less bandwidth, it out¬ 
performs the crossbar over time. 

Now consider the performability distri¬ 
bution in Figure 12, 7 which shows the time- 
averaged bandwidth distribution of the 
16x16 C.mmp crossbar architecture. The* 
axis represents the bandwidth (reward x), 
and the y axis denotes the distribution 
probability averaged over a time span f, 
P[Y(t)/t >x]. Ideally, as t -> 0, the crossbar 
provides its maximum bandwidth of 10.3 
(the vertical line). More realistically, the 
probability distribution curve reaches zero 
for a nonzero time span when the band¬ 
width x increases. For example, the proba¬ 
bility of attaining a bandwidth of 10 for a 
mission time of 100 hours is less than 1 
(about 0.9) due to component failure. This 
type of information is important when as¬ 
sessing an architecture’s suitability for a 
specified task. 

Software packages 

Many software tools have been devel¬ 
oped for analyzing the dependability of 
complex systems. (Johnson and Malek have 
written a detailed survey of these tools. 3 ) The 
tools discussed below are a good sample of 
those available and cover most modeling 
techniques and objectives. 


The Automated Reliability Interactive 
Estimation System (ARIES) was one of the 
first tools for predicting the reliability of 
repairable and nonrepairable systems. It 
uses homogeneous Markov chain models 
for determining reliability, mean time to 
first failure, and the reliability improve¬ 
ment factor. It cannot model general fail¬ 
ure distribution. 

NASA Langley Research Center and 
Raytheon have developed a software pack¬ 
age called Computer-Aided Reliability Es¬ 
timation III (CARE III) to model highly 
reliable nonrepairable systems. It accepts 
fault trees, nonhomogeneous Markov 
chains, and semi-Markov chains as input. 
The model provides numerical values or 
graphical plots of reliability and coverage 
data. It cannot model repairable behavior. 

The Hybrid Automated Reliability Pre¬ 
dictor (HARP) was developed at Duke 
University and is now available through 
NASA Langley. It can compute the reli¬ 
ability and instantaneous availability of 
nonrepairable and repairable systems, re¬ 
spectively. HARP implements a fault oc¬ 
currence and repair model that uses Mark¬ 
ov chains with multiple distributions, and a 
fault- and error-handling model with seven 
types of analytical modeling techniques. It 
converts a fault tree to a Markov chain or 
accepts a Markov chain representation as 
input. It cannot compute steady-state 
availability or mean time between failures. 


The System Availability Estimator 
(Save), developed at IBM, evaluates the 
reliability and availability of nonrepair- 
able and repairable systems. It uses a ho¬ 
mogeneous Markov chain model to calculate 
steady-state availability, sensitivity, and 
mean time to failure. Save accepts system 
descriptions in a high-level language and 
solves the model using either a Markov or 
Monte Carlo simulation approach. The 
model is restricted to exponential distribu- 

The Symbolic Hierarchical Automated 
Reliability and Performance Evaluator 
(SHARPE), being developed at Duke Uni¬ 
versity, is intended to provide a hybrid and 
hierarchical way to evaluate the reliability 
and availability of nonrepairable and re¬ 
pairable systems. It is also intended for use 
in evaluating performance-related de¬ 
pendability. This tool will accept reliabil¬ 
ity block diagrams, fault trees, or Markov 
chains as input for predicting reliability 
and both transient and steady-state avail- 

While these evaluation tools are sophis¬ 
ticated enough to analyze complex systems, 
most of them require a reliability block 
diagram, fault tree, or Markov chain as 
input, which limits their usefulness for 
large multiprocessor architectures. Unless 
the dependability model is very simple, it 
is extremely difficult to develop any kind 
of input model for a large multiprocessor. 
When the solution involves a Markov ap¬ 
proach, the size and nature of a single-level 
Markov chain makes these tools particu¬ 
larly inadequate. A hierarchical approach 
(divide and conquer) seems necessary to 
evaluate multiprocessors with these tools. 
Such an approach would divide a system 
into several subsystems, with each sub¬ 
system evaluated independently before the 
complete system is examined. 


A lthough we have focused on four 
types of architectures (due to their 
commercial availability), a num¬ 
ber of other topologies for parallel-system 
design have been proposed. 

As more powerful systems evolve, their 
evaluation will depend largely on the orga¬ 
nization of their interconnection networks. 
Each such network must be addressed by 
an appropriate model. We expect that the 
practicality of task-based evaluation will 
make it the metric of choice. Future shared- 
memory systems could use an approach 
like the MIN modeling techniques dis¬ 
cussed by Das, Tien, and Bhuyan, 9 and 
distributed memory systems could build 
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on the hypercube model developed by Das 
and Kim. 10 

The modeling and evaluation of parallel 
computers is an evolving research area. 
Most models address only hardware fail¬ 
ure. A more realistic evaluation requires 
the inclusion of software faults and differ¬ 
ent types of transient and intermittent faults. 
Performance-related dependability evalu¬ 
ation of parallel computers is another ac¬ 
tive research area. We need more meaning¬ 
ful, as well as powerful, models for specific 
multiprocessor architectures. In turn, these 
should motivate researchers to develop more 
sophisticated software tools to aid in anal- 
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A System Architecture for 
Fault Tolerance in 
Concurrent Software 


Massimo Ancona, Gabriella Dodero, and Vittoria Gianuzzi, University of Genova 
Andrea Clematis, Italian National Research Council 
Eduardo B. Fernandez, Florida Atlantic University 


R obotics, process control, naviga¬ 
tional systems, and other critical 
computer applications demand re¬ 
liable software. Such systems generally 
comprise a set of concurrent, cooperating 
processes. 

Several researchers have developed 
methods and tools that use redundancy to 
help critical systems tolerate errors caused 
by software faults. Two of the most widely 
used techniques for sequential software 
are recovery block programming 1 and In¬ 
version programming. 2 The most suitable 
mechanisms for concurrent systems are 
programmer transparent coordination 3 and 
conversation. 1 All four of these approach¬ 
es are general and apply to any type of 
computation. We can consider them dif¬ 
ferent types of design diversity. (The sidebar 
titled “Software fault-tolerance techniques” 
details the approaches.) 

Unfortunately, the few languages that 
provide adequate syntax and runtime sup¬ 
port to implement fault-tolerant mecha¬ 
nisms are still experimental. Usually, the 
programmer must describe the desired fault- 
tolerance policy explicitly, greatly compli¬ 
cating the program’s implementation, 
readability, and maintenance. 

Programmers need an environment that 
effectively supports the development of 
fault-tolerant programs. At the very least, 
such a system must let the user 


Our proposed 
architecture separates 
the application 
from the recovery 
software, giving 
programmers a single 
environment that lets 
them use the most 
appropriate 
fault-tolerance scheme. 


select and apply the most suitable fault- 
tolerant mechanism for the application 
program; 

modify that mechanism as required by 
the program or to experiment with new 
fault-tolerance schemes; and 
modify and maintain the application 
program without interfering much with 
the recovery structure. 


Our proposed system architecture ful¬ 
fills these requirements and can support a 
variety of policies in a structured way. It 
treats the application program and the re¬ 
covery software — called the Recovery 
Metaprogram —separately. The RMP acts 
like a programmer who monitors and (pos¬ 
sibly) modifies the execution of the appli¬ 
cation program. (The sidebar titled “Other 
similar approaches” discusses how other 
researchers are handling fault tolerance in 
related ways.) 

To simplify our presentation of the RMP 
approach, we will assume that the fault 
model is limited to faults originating in the 
application software, and that the hard¬ 
ware and kernel layers can mask their own 
faults from the RMP. Also, we will not 
consider relationships between backward 
and forward error recovery. Exceptions at 
other layers will be handled within those 
layers; they will not be signalled to the 
RMP, and no other exceptions will be raised 
within the RMP. 

Recovery architecture 

Our software fault-tolerance architec¬ 
ture contains three main components: the 
application component, the recovery com¬ 
ponent, and the kernel. 

The application component is the user’s 
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view of the computational system, for ex¬ 
ample, as a set of communicating process¬ 
es. In the recovery component, the RMP 
coordinates the application program’s ex¬ 
ecution. The RMP is basically a set of 
processes that implement fault-tolerance 
mechanisms. The kernel implements an 
ordinary multiprocessing kernel augment¬ 
ed by a set of fault-tolerance primitives, 
which the RMP invokes as kernel requests. 


The kernel also maintains data structures 
relevant to process management; RMP calls 
can update some portions of these struc¬ 
tures. This organization can support any 
fault-tolerance policy specified in the 
RMP. 

Figure 1 illustrates the relationship be¬ 
tween the application program and the RMP 
and shows how the RMP superimposes the 
recovery block control structure on an ap¬ 


plication program. The kernel is the medi¬ 
um between them. 

In practice, the RMP monitors the appli¬ 
cation program much as a programmer 
observes software through a debugger. The 
RMP inserts a number of breakpoints in the 
program. When one of them is reached, the 
application program is suspended and the 
kernel activates the RMP, which performs 
actions to support the chosen fault-toler- 


Software fault-tolerance techniques 


Sequential 

The recovery block construct is based on checkpointing 
and redundancy. Several alternate try blocks, all implement¬ 
ing the same functionality, combine to achieve one fault- 
tolerant execution. At block entry, the program status is 
saved and the first alternate is executed. The computed re¬ 
sults are checked before block exit. If this acceptance test 
fails, the computation is rolled back to block entry status and 
an alternate try block is executed. 

Assume that two alternate functions, SqrtA and SqrtB, both 
implement the square root function. The syntax Randell 1 pro¬ 
poses for such a recovery block is then 

ensure lx 2 - yl < tolerable 

by x := SqrtA(y) 

else by x := SqrtB(y) 

else error 

A/-version programming uses redundancy to mask software 
faults. Several different versions of the same software exe¬ 
cute, and some hardware or software unit compares their 
computed results. The majority result is accepted. To achieve 
a fast response time, the different versions usually execute in 
parallel on different machines. Checkpointing and rollback 
are not required in this case, but different initial status copies 
must be created. 

Concurrent 

Applying recovery block or N-version programming 
schemes without coordination in concurrent programs can in¬ 
cur a domino effect, 1 since errors can be exported to other 
processes via communication. For example, a fault requiring 
a rollback in one process can provoke a rollback in another 
process because of communication between them. This, in 
turn, could affect the whole set of processes, causing the 
computation to restart from its initial state. Thus, recovery 
block or /V-version programming mechanisms must be ex¬ 
tended to apply to concurrent environments. 

The conversation scheme is essentially a concurrent exten¬ 
sion of the recovery block scheme in which a group of pro¬ 
cesses can interact safely. Each process entering a conver¬ 
sation is checkpointed. To prevent information smuggling 
(that is, spreading data that has not been validated), 4 the pro¬ 
cess can then communicate oniy with processes that are al¬ 
ready in the conversation. When all processes have complet¬ 


ed their operations, a global acceptance test occurs. If it fails, 
all processes roll back and execute their next alternates; if it 
is satisfied, all processes discard their checkpoints and exit 
synchronously from the conversation. 

The conversation scheme guarantees that no subsequent 
error can roll a process back to a point before a successful 
acceptance test; hence, no domino effect can occur. Several 
implementations have been proposed in the literature to ex¬ 
tend and adapt this scheme to various environments and pro¬ 
gramming styles. 

Let’s assume that conversation Cl involves m processes, 
P 1: ..., P m , and that the global acceptance test is the logical 
AND of the various processes’ acceptance tests. The portion 
of P, involved in Cl can be specified, for example, as a 
name-linked recovery block, 4 that is, a recovery block with n 
alternates and with Cl as a prefix: 

Process PI = ... 

\V definition of procedures 
P1C1,, P1C1 2 ,. . . P1C1 n , and 
error, and of the Boolean 
function ATPlCt *\\ 

begin . .. 

Conv Cl 
ensure ATP1C1 

by PI Cl, 
else by P1C1 2 

else by P1C1„ 

end Conv 

An alternative mechanism for defining a group of consistent 
recovery points is programmer transparent coordination. PTC 
relies on an intelligent processor, which prevents the domino 
effect by automatically taking additional recovery points with¬ 
in recovery blocks defined in a process. Therefore, a pro¬ 
grammer can use recovery blocks freely in each process 
without worrying about coordinating checkpoints and roll¬ 
backs in other processes. 

PTC differs from conversation in that the programmer must 
explicitly state conversation boundaries, while PTC is a trans¬ 
parent mechanism. Also, the conversation acceptance test is 
synchronous, while PTC lets processes proceed indepen¬ 
dently as long as a process executing a recovery block keeps 
the corresponding checkpoints until all related recovery 
blocks in other processes have succeeded. 
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Figure 1. Control flow between the application program and the Recovery 
Metaprogram. 


main call: 


10 SqrtA(X,Y) 

20 Continue 


subroutines: 

Subroutine SqrtA(. ..) 

//* 1st alternate *// 

End 


Subroutine SqrtB(. ..) 

//* 2nd alternate *// 

End 


Logical function Verify(. . . 

) //* acceptance test *// 

End 



ance mechanism. The RMP is then sus¬ 
pended again, and the application program 
is reactivated until the next breakpoint is 
reached. 

The application program. Our system 
lets users limit their intervention in the 
application software to indicating which 
portions of the program are involved in 
fault tolerance. Control-flow specification 
is left to the RMP. For instance, program¬ 
mers can use labels to specify recovery 
points, and some Boolean functions can be 
chosen as the validation tests. 

Such a scheme requires a programming 
tool to support the interface between the 
application and the RMP. This tool must 
collect information on the portions of the 
application program to be monitored by 
the RMP as well as implement the program 
code to allow control transfers, as shown in 
Figure 1. 

We will now use two examples — the 
recovery block and the conversation — to 
detail how an application can specify a 
mechanism. 

The recovery block. Consider what hap¬ 
pens if we want to use recovery blocks in 
the Fortran program in Figure 2. (For ease 
of reference, we consider alternates to be 
procedures and, therefore, named entities.) 

We cannot insert a special construct in a 
Fortran program to specify that procedures 
SqrtA and SqrtB are alternates and that 
SqrtB should execute only if SqrtA fails 
the acceptance test (Verify). Thus, the pro¬ 
gramming environment must collect in¬ 
formation about these components, and 
any links among the procedures must be 
expressed in the RMP, where a recovery 
block mechanism is made explicit to acti¬ 
vate them. To specify the control flow, the 
RMP must be able to reference the begin¬ 
ning, end, and other components of the 
recovery block, such as labels 10 and 20, 
SqrtA, SqrtB, and Verify. 

Conversation. We use the syntax in Fig¬ 
ure 3 if there is no construct to define 
which portions of process PI participate in 
conversation Cl. If software fault toler¬ 
ance is not needed, control flow consists 
simply of the execution of procedure P1C1!. 
Otherwise, the RMP coordinates execu¬ 
tion in a manner similar to the recovery 
block scheme; for example, P1C1 2 is acti¬ 
vated if P1C1, fails. 

We can use basically the same RMP 
both with languages that support dedicated 
fault-tolerance constructs and with lan¬ 
guages that do not support them. In the 


Figure 2. Recovery block example. 


latter case, a specific tool in the program¬ 
ming environment gives the RMP infor¬ 
mation about the application. 

The RMP view of the application com¬ 
ponent. At least the following items must 
be defined in the application program and 
made accessible to the RMP: 

• The entry points (that is, the beginning 
and end) of each portion of an application 
process under RMP control. Constructs 
denoting entry points vary according to the 
application language; for instance, labels, 
pragmas, or separate descriptive units can 
be used. 

• The alternates for an execution path, to 
be executed in sequence (recovery block) 
or in parallel (V-version programming). 

• The validation test, a Boolean function 
without side effects. 


Process P t = 

//* definition of procedures 

PIO^PIC^_PlCl n , and 

error, and of the Boolean 
function ATP1 Cl *11 

begin . .. 

Clinit; 1C11 
Cl end: . . . 


Figure 3. Conversation example. 


Since each of these entities will belong 
to some process, the RMP must know the 
set of application processes. The RMP also 
must know the environment of a process, 
that is, the set of all current valid associa- 
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Other similar approaches 

Crespi and Natali 1 have proposed superprograms to extend 
existing languages with fault-tolerant features. Superpro¬ 
grams operate on application program entities such as pro¬ 
cesses and data structures, as well as on resources provided 
by the execution environment. The language for such a struc¬ 
ture uses debugging-like commands, some application-like 
constructs, and hardware configuration descriptions. The 
RMP is an extension of this supervisory-program concept. 

(We presented an earlier version of our architecture in a pre¬ 
vious work. 2 ) 

Researchers are showing greater interest in unifying vari¬ 
ous software fault-tolerance techniques. For example, Laprie 
et al. 3 have proposed a structured definition for architectures 
offering fault tolerance in both hardware and software. They 
consider and evaluate specific software fault-tolerance archi¬ 
tectures — recovery block, A/-version programming, and N- 
version self checking — with respect to their reliability. Their 
global view considers special treatment of specific classes of 
faults or techniques only when necessary. 

Purtilo and Jalote 4 have proposed a system to implement 
the recovery block and /V-version programming schemes in 


multiple programming languages. Their goal was to ensure 
diversity by letting programmers develop redundant modules 
in different languages. 
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tions between variables and values. An 
environment with no valid associations is a 
faulty environment resulting from a soft¬ 
ware error. 

Environments can constitute checkpoints 
for a rollback strategy. Depending on the 
chosen fault-tolerance strategy, the RMP 
specifies when such checkpoints must be 
saved, restored, duplicated, discarded, or 
used in process execution. The kernel im¬ 
plements these operations using either 
hardware or software resources (for exam¬ 
ple, stable storage, clone processes, and 
virtual memory). 


To be managed by the RMP, an entity 
must be one of a set of dedicated data types 
defined in the RMP implementation lan¬ 
guage (see Figure 4). With these types, we 
can classify the entities in Figure 2 as 
follows: Labels 10 and 20 are Entrypoints, 
SqrtA and SqrtB are Codesections, and 
Verify is the Validationtest. We can define 
the entities in Figure 3 in a similar manner: 
Clinit and Clend are Entrypoints, proce¬ 
dures PlClj, P1C1 2 , P1C1„, and error are 
Codesections, and function ATP1C1 is the 
Validationtest 

We can also construct sets out of pro¬ 


cesses or environments and handle them 
with the usual set operators for testing 
membership, union, cardinality, and the 
like. 

The kernel interface to the RMP. The 

kernel provides the operations on entities 
belonging to the above data types. Figure 5 
lists the primitives that invoke these ser¬ 
vices, using the following syntax: input 
parameters to kernel calls are in parenthe¬ 
sis, while call results follow a colon. 

The Save, Discard, Restore, and Contin¬ 
ue functions update process-related infor¬ 
mation in the kernel and return to the RMP 
without rescheduling (that is, the applica¬ 
tion program is not activated). 

The Restrict function controls interpro¬ 
cess communication and prevents infor¬ 
mation smuggling among processes in 
conversation schemes. Processes usually 
communicate directly via messages or in¬ 
directly via monitors or remote procedure 
calls. Most proposed conversation schemes 
require that the kernel controls communi¬ 
cation. 

Caller and Where_Is are query func¬ 
tions. The Execute, Evaluate, Vote, and 
Terminate functions all suspend the RMP, 
activate (or abort) the specified process on 
the specified procedure after rescheduling, 
and reactivate the RMP when the proce¬ 
dure has executed (or been forced to ter¬ 
minate). 


Process — An application process instance (compatible with the process type as 
managed by the kernel). 

Entrypoint — An address in the process code area. When no value is needed, the 
constant Nil is used. 

Codesection — An application process procedure. 

Validationtest — A Boolean function with no side effects. 

Environment — A representation of a process’ current data area. A faulty 
environment is denoted by the constant Faulty, and an empty (not initialized) 
environment by Empty. The environment in use at a given moment is Current. 


Figure 4. RMP data types. 
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The parameters in Figure 5 are minimal; 
more can be added. For instance, processor 
identification can be inserted if distributed 
execution is needed. 

The RMP structure. We have discussed 
the RMP data types and a minimal set of 
kernel primitives, but what about the RMP’s 
language and general structure? 

Since the RMP monitors the application 
program, it is responsible for issuing suit¬ 
able kernel calls to initialize and subse¬ 
quently activate the program’s processes. 

The RMP repeatedly invokes the Continue 
primitive to tell the kernel to set all pro¬ 
cesses to the ready state and start their 
processing. The RMP then waits until at 
least one process reaches an entry point and 
suspends execution. 

Since many RMP actions can execute 
concurrently, it is preferable — although 
not mandatory — to express the RMP in a 
concurrent language. The kernel imple¬ 
ments a concurrent virtual machine on top 
of any type of hardware, but given a dis¬ 
tributed or multiprocessor system, the 
specification of concurrent activities in the 
RMP could lead to distributed execution as 
well. 

We specify the RMP in the Communi¬ 
cating Sequential Processes 5 language, 
which provides an elegant and concise 
notation for expressing RMP actions. We 
use a slightly extended notation for guards; 

at Entrypoint value —> Process 

which means the process is activated when 
the application process is suspended at the 
specified address. Figure 6 summarizes the 
other CSP notations. 

RMP examples 

The following examples use the data 
structures shown in Figure 7. We omit Figure 5. Kernel primitives, 
some of the subscripts when they are clear 
from the context. All the data structures 
have values generated by the compiler (or 
some tool of the programming environ¬ 
ment) and are accessed by the RMP as read¬ 
only data (with the exception of CVenteredj 
and variables of the Environment type). 

The first statement of the RMP main 
program activates all processes defined in 
the application program; 

Pset (Continue^,-, start,. Empty, false))'. 

After that, a number of RMP processes are 
started in accordance with the chosen strat- Figure 6. Communicating Sequential Processes (CSP) symbols. 


Notation 

Meaning 

P.Q 

Processes 

(a P 1 b^Q) 

a then P choice b then Q 

(a and b are guards of the two processes P and Q) 

P II Q 

P in parallel with Q 

iJ< n Pi 

P 1 II P 2 II ... II P n 

*P 

repeat P 

b* P 

while b repeat P 


Sa ve(Process): Environment — A checkpointing primitive. The current 
environment of the referenced process is saved and its name returned as a 
result. 

Discard {Environment) — The specified environment is discarded. 

Restor e(Process, Environment) — The environment previously saved is 
restored. 

Continue(/Voces.s, Entrypoint, Environment) — The process’ status is set to 
ready; it will be reactivated from the specified address. 

Restrict(Procej5, set of Processes, set of Processes) — A communications 
restriction on the specified processes. The first process can communicate only 
with processes in either of the other two sets. This allows asynchronous 
entrance into a conversation in three ways: 

• Communication to (or from) processes in the first set can be performed 
immediately. 

• Communication to (or from) processes in the second set delays the sending 
(or receiving) process until a subsequent Restrict operation allows the 
communication (this is required to implement asynchronous entry). 

• Communication to (or from) a process outside either set causes a 
nonrecoverable error in the sending (or receiving) process (its environment 
becomes faulty). 

Caller (Process): Process — If the input parameter is a monitor or a remote 
procedure, the output value is the process for which the monitor is working. 

Where_Is(/ ) rocf?.v.v): Entrypoint — If the process is idle or waiting, the returned 
value is the address at which it is suspended. Otherwise, it is Nil. 

Execut e(Process, Codesection, Environment): Environment — Starts execution 
of the application process with the indicated code section and environment. 
Activation returns an environment, which can be faulty if an error has occurred. 

EvaluatelPror e.w, Validationtest, Environment): Boolean — Returns the 
Boolean result of the validation test performed on the given environment. If the 
actual environment parameter is Faulty, the result is “false.” 

Vot e(Validationtest, set of Environments): Environment — The environments 
listed as input parameters are compared by the given validation test, and the 
resulting environment is returned. The application program specifies the voting 
policy in the Validationtest function. 

Terminate(ProceM) — The specified process aborts (after a nonrecoverable 
error). 
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Pset — Set of processes defined in the application program. 

Pi — ith process of Pset. 

start i — Start address of process p r 

entry q — Entry point of process p, in the jth controlled block. 

exitjj — Exit point of process p, in the /th controlled block. Start,, entry q, and 
exitij are of the Entrypoint type. 

CSeCijh — Procedure defined in process p„ in the y'th controlled block, 
implementing the kxh alternate ( Codesection type). 

VTestjj — Validation test defined in p, and relative to the jth controlled block 
( Validationtest type). 

RBset — Set of recovery blocks defined in the application program. 

NVset — Set of N- version programming blocks defined in the application 
program. (Since recovery blocks and V-version programming blocks are 
defined in sequential processes, we can assume there is only one process p e 
Pset.) For each RBj e RBset (or NVj e NVset ) we define 

• the final acceptance test VTestj (for RBj only), 

• the number of alternates n ; , and 

• for each alternate, CSec J:k (1 < k < nj) (indicates the appropriate procedures). 

CVset — Set of the conversations defined in the application program. For each 
CVj 6 CVset we define 

• the set of participating processes CVsetj = {p,} (this set is the same for every 
alternate of CVj), 

• the set of those processes actually participating in CVj at any given instant 
CVenteredj (since they can enter asynchronously), 

• the final acceptance test VTest h j for each process, 

• the number of alternates «,■, and 

• CSeCijj. (1 <k< nj), indicating one alternate procedure ( CodeSection type). 
id 1, idl, etc. — Variables of the Environment type. 


Figure 7. RMP data structures. 


RBproc = (idl := Save(p); k := 1; bool := false; 

((-ibool) & (k < n)) * (id2 := Execute(p, CSec k , idl); 

bool := Evaluate (p, VTest, id2); 
k := k + 1); 

Discarded 1); 

if -ibool then Terminate(p) else Continue(p, exit, id2)) 


Figure 8. A generalized process, RBproc, to execute any recovery block in any 
process. 


egy (recovery block, IV-version program- Recovery block. Implementing a re- 
ming, conversation, or programmer trans- covery block requires properly organizing 
parent coordination), each monitoring its the basic actions: saving a process’ state, 
corresponding program portion. executing the nth alternate, executing the 


acceptance test, and discarding or restor¬ 
ing a saved state. We can use a generalized 
process, RBproc, to execute any recovery 
block in any process (see Figure 8). 

When RBproc starts, it saves the current 
environment of process p and assigns its 
value to idl. The result of the execution of 
the first alternate defined in the recovery 
block is idl. The related acceptance test is 
then executed using idl. If the result is “true” 
(that is, if the alternate executes success¬ 
fully), environment id 1 is discarded and 
process p continues in environment idl. 
Otherwise, the next alternate executes, again 
in environment idl. 

We implement the rollback and the re¬ 
sumption of the original checkpointed en¬ 
vironment by making the environment in 
which a process must execute a parameter 
of the Execute function. Retries continue 
until an alternate succeeds or until no more 
alternates are available. In the latter case, 
the RMP could perform any suitable ac¬ 
tion; in Figure 8, the Terminate function is 
invoked for the sake of simplicity. 

The kernel calls to Execute and Evaluate 
suspend RMP execution and transfer con¬ 
trol to process p. Specifically, the Execute 
call makes the CSec k procedure of p execute 
in idl. Control then returns to the next 
RMP statement (the Evaluate call). 

RBproc must be activated each time the 
application program enters the recovery 
block, that is, each time the application 
program is executing at some recovery 
block entry point. Assuming that only one 
recovery block is present in process p and 
that its entry point is labeled “entry,” we can 
suspend the application program and trans¬ 
fer control to RBproc by including the 
following statement in the RMP main pro¬ 
gram: 

at entry -> RBproc 

Now consider a process p in which sev¬ 
eral disjoint recovery blocks have been 
defined or in which a recovery block is 
defined inside an iteration. It is difficult or 
impossible to know the order in which 
these recovery blocks will be activated. 
We must generalize the simple structure of 
the RMP main program above. The choice 
statement makes this possible, j 

Let’s call RBj one of the recovery blocks 
defined in RBset (see Figure 7). Since one 
RMP process must be implemented for 
each RBj in RBset, the RMP main program 
must contain the following choice state- 

*( rb i RBset at entry j —> RBproc j ) 
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Application program 

10: Kernelcall; 


SqrtA: first alternate; 

Kernelcall; 


Verify: acceptance te 

Kernelcall; 


second alternate; • 
Kernelcall; 


Verify: acceptance test; 

Kernelcall; 


Recovery Metaprogram 


• idl := Save(p); k := 1; bool := false 
■ id2 := Execute(p, SqrtA, idl); 


; bool := Evaluate(p,Verify, id2); 


• k:=k+ 1; 

(* bool = false & k < 3 *) 

■ id2 := Execute(p, SqrtB, idl); 


: bool := Evaluate(p,Verify, id2); 


Figure 9. Control flow between the application program and RMP. 


RMP main: 

*( NV l NVset at entryj —> NVprocj) 
where NVproc, is: 

NVprocj = (id := Save(p); 

l < k < nj id2 k := Execute(p, CSeCj k , id); 

id := Vote(VTestj, id2); 

if id = Faulty then Terminate(p) 

else ( j sisn ; Discard(id2 k ); 

Continue(p, exit,, id, true)) 

) 


Figure 10. The V-version programming process. 


where each RBprocj is a y'th instance of 
RBproc. 

The choice construct lets us express RMP 
processes without knowing the application 
program’s control flow. While the RMP 
main program is suspended on the above 
guarded statement, the application processes 
continue to work until one of the entryj 
addresses is attained, making the corre¬ 
sponding guard successful and forcing the 
execution of the RMP process RBprocj. At 
the end of RBprocj, the RMP process again 
waits for a possible subsequent execution 
of this or some other recovery block. 

Figure 9 shows the control flow between 
the RMP and the application program for 
the recovery block in Figure 2, assuming 
that the first alternate fails. Note that Fig¬ 
ure 9 is a refinement of Figure 1. Figure 9 
also shows that, compared with other im¬ 
plementations of the same fault-tolerance 
actions, the RMP incurs an additional cost 
in the form of extra context switches. On 
the other hand, the RMP data is protected 
from application program interference. 

V-version programming. We can im¬ 
plement V-version programming in a sim¬ 
ilar manner (see Figure 10). Note that the 
parallel construct on the Execute function 
implies that the same environment, idl, is 
replicated for each activated process. This 
implementation is not tied to a specific 
hardware architecture, that is, the parallel 
construct can be interpreted in different 
ways depending on the target. We must add 
at least one parameter to this kernel function 
to handle possible parallelism in the target. 

Conversation. This implementation re¬ 
fers to the name-linked recovery blocks 
and assumes that there are no nested con¬ 
versations, that participants for every al¬ 
ternate are the same and statically known, 
that participants enter the first alternate 
asynchronously and subsequent ones syn¬ 
chronously, and that the environment is 
centralized. 

Figure 11 shows the process implement¬ 
ing conversation CV, which involves the 
set of processes CVset. If many conversa¬ 
tions have been defined, each conversation 
CVj will coordinate actions performed by 
processes in CVsetj. 

We must implement the processes in 
Figure 11 differently for different imple¬ 
mentations of the conversation scheme. 
For instance, nested conversations require 
manipulation of a stack of process sets, and 
a distributed implementation requires a two- 
phase “like” protocol to execute the global 
acceptance test. 6 


Programmer transparent coordina¬ 
tion. Kim describes programmer transpar¬ 
ent coordination 3 as a system where recov¬ 
ery blocks have been defined and processes 
interact through monitors, so that recovery 
actions involve monitor reference and up¬ 
date operations. 

The algorithm initially considers only 
one monitor, p m , which does not contain 
Wait or Signal instructions (see Figure 12). 
The monitor provides Update and Refer¬ 
ence operations, with entry points named 
p m upd.entry and p m ref entry, respectively. 
Additional recovery points, called branch 


RPs, are established within each process 
and the monitor according to information 
received from other processes. At any giv¬ 
en moment during program execution, we 
refer to the set of recovery blocks that has 
information on which process A depends as 
the direct potential recaller set, or DPRS(X). 
The algorithm also contains rules to dis¬ 
card or resume the branch RPs depending 
on the successful or failed execution of a 
recovery block. 

Unlike the recovery block and conversa¬ 
tion schemes, we cannot easily implement 
the PTC scheme in a structured way. The 
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RMP main: 

* (CVentered := 0; 

( p,e cv<et at entry's -» CVproc,); 

Conv) 

CVproCj = (idl, := Save(pj); 

CVentered := CVentered u {p;}; 

(p k e CVentered) *( Restrict(p k , CVentered, CVset)); 
id2j := Execute(pj, CSeCj !, idl;)) 

Conv = (k := 1; bool := false; 

(-1 bool) *( (Jcvset b; := Evaluate(p i; VTesq, id2j)) 
bool := true; 

(pi € CVset) *(bool := bool & b ; ); 
bool ;= bool or (-i bool & (k = n)>; 
k := k + 1; 
if bool then skip 

else p , e cvsct id2j := Execute^, CSec i>k , idl;)); 
if (k £ n) then Proceed else p . e CVse t Terminate(pi) 

| "):".■ 

Proceed »( p . e evset (Discarded 1;); 

RestrictCp;, Pset, Pset); 

Continue(p;, exit,, id2 i( true)) 

illlllil! 

If more than one conversation is defined in the application program, we must 
instantiate one such RMP process for each conversation: 

*( cv | CVset *(CVenteredj := 0; 

p I eVsetj at entryjj -> CVproc i( j; 

Convj) 


Figure 11. The conversation process. 


CSP program in Figure 12 implements 
Kim’s rules related to the set of branch RPs 
and the evaluation of the DPR set. The 
processes SucCjj and Faily are referred to 
but not shown in Figure 12; they perform 
the operations Kim defined. 3 

Since any of these four fault-tolerance 
strategies could be used in an application 
program, the RMP execution framework 
lets us apply the most suitable strategy for 
a particular situation. The RMP also lets us 
observe the application under different 
control policies to “fine tune” its behavior. 

RMP modules implementing new fault- 


tolerance constructs and improved versions 
of old ones also have been developed, in¬ 
cluding a real-time extension of the recov¬ 
ery block scheme and a version of the 
conversation scheme that relaxes the syn¬ 
chronous acceptance test condition. 

RMP implementation 

Ozaki et al. have described a possible 
implementation of some of the primitives 
required by the RMP, using existing K286 
primitives on 80286-based machines. 7 The 
K286 primitives include task management 


and scheduling operations, memory man¬ 
agement support (segment creation and 
sharing), and intertask communication by 
use of mailbox primitives. Ozaki et 
al.showed how combining such primitives 
can support higher level operations used 
by the RMP. 7 

The programming environment. We 

have implemented a programming envi¬ 
ronment based on the Cross Multimicro 
Development System for multimicro em¬ 
bedded applications. 8 CMDS is based on 
the host-target approach and supports a 
high-level modular concurrent language, 
called the Multimicro Language (MML). 
(However, the actual organization of ex¬ 
tensions to CMDS is largely independent 
from language or environment features.) 

CMDS provides a set of tools on the host 
system based around a compiler and an 
allocator. The compiler can generate code 
for different target machines, while the 
allocator lets us assign the target system’s 
physical resources to an MML program’s 
logical entities. Runtime support for MML 
consists of a multiprocessor kernel devot¬ 
ed to basic I/O, message passing, and pro¬ 
cess scheduling. 

We write fault-tolerant MML applica¬ 
tions using Extended MML, a version of 
MML with a few syntactical constructs to 
define program parts that the RMP needs to 
supervise. Two tools have been added: a 
preprocessor for application programs and 
the RMP builder. 

The preprocessor analyzes an Extended 
MML program and outputs an MML pro¬ 
gram plus information about its fault-toler¬ 
ance needs. The compiler can then process 
the MML program, inserting kernel calls in 
the application program code correspond¬ 
ing with required switches between the 
application and the RMP (see Figure 9). 

Using the fault-tolerance information 
from the preprocessor, the RMP builder 
extracts from the RMP library the appro¬ 
priate modules to implement the selected 
fault-tolerance mechanisms and configures 
them into an RMP component. Figure 13 
shows the information flow through such 
an environment. 

Let’s again consider the example in Fig¬ 
ure 2. Assuming the two alternates (SqrtA 
and SqrtB) and the acceptance test (Verify) 
are written in MML, the preprocessor 
outputs a table naming these components 
as well as the entry and exit points. The 
RMP builder then inspects this table, ex¬ 
tracts from the RMP library the recovery 
block module, and configures it as a process 
initialized with the collected information. 
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W e can view the Recovery 
Metaprogram as a unifying 
mechanism that lets us imple¬ 
ment different software fault-tolerance 
concepts in different contexts. As such, the 
RMP gives us a better understanding of 
how to incorporate fault-tolerance func¬ 
tions into application programs. We can 
use this insight, in turn, to develop im¬ 
provements or extensions to existing 
mechanisms. 

The reusability of the RMP processes is 
an additional advantage of the RMP ap¬ 
proach, since most of the processes can be 
application independent. Separating the 
concerns of application design and devel¬ 
opment from those of fault-tolerance spec¬ 
ification helps promote understanding of 
both and might result in increased system 
reliability. ■ 
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D igital computers have become es¬ 
sential to critical real-time appli¬ 
cations such as aerospace systems, 
life support systems, nuclear power plants, 
drive-by-wire systems, and computer-in¬ 
tegrated manufacturing systems. Common 
to all these applications is the demand for 
maximum reliability and high performance 
from computer controllers. This require¬ 
ment is necessarily stringent because a 
single controller failure in these applica¬ 
tions can lead to disaster. For example, the 
allowable probability of failure for a com¬ 
mercial aircraft is specified to be less than 
10~ 9 per 10-hour mission because a con¬ 
troller failure during flight could result in a 
crash. 

Because of such stringent requirements, 
traditional methods for design and valida¬ 
tion of computer controllers are often in¬ 
adequate. Ad hoc techniques that appear 
sound under a careful failure-modes-and- 
effects analysis are often susceptible to 
certain subtle failure modes. The clock 
synchronization problem shown in Figure 
1 is a classic example. The figure shows a 
three-node system in which each node has 
its own clock. The clocks are synchronized 
by adjusting each to the median of the three 


Software algorithms 
are suitable only where 
loose synchronization 
is acceptable, and 
hardware algorithms 
are expensive. A hybrid 
scheme achieves 
reasonably tight 
synchronization and is 
cost-effective. 


clock values. This “intuitively correct” al¬ 
gorithm works fine as long as all the clocks 
are consistent in their behavior, as Figure 
la illustrates. However, if one clock is 
faulty and misinforms the other two clocks, 


the two nonfaulty clocks cannot be syn¬ 
chronized. For example, in Figure lb the 
faulty clock B reports incorrectly to clocks 
A and C. As a result, clocks A and C do not 
make any corrections because both behave 
as if they are the median clock. 

Lamport and Melliar-Smith were the first 
to study the three-clock synchronization 
problem in the presence of arbitrary fault 
behavior. 1 They coined the term Byzantine 
fault to refer to the fault model in which a 
faulty clock can exhibit arbitrary behavior 
including, but not limited to, misrepresent¬ 
ing its value to other clocks in the system. 
They showed that in the presence of Byz¬ 
antine faults, no algorithm can guarantee 
synchronization of the nonfaulty clocks in 
a three-node system. They also showed 
that 3m + 1 clocks are sufficient to ensure 
synchronization of the nonfaulty clocks in 
the presence of m Byzantine faults. This 
condition later proved not only sufficient 
but also necessary for ensuring synchroni¬ 
zation in the presence of Byzantine faults. 

Since the initial study by Lamport and Mel¬ 
liar-Smith, the problem of clock synchroniza¬ 
tion in the presence of Byzantine faults has 
been studied extensively by several other re¬ 
searchers. All this attention is mainly be- 
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cause many applications require a consistent 
view of time across all nodes of a distributed 
system, and this can be achieved only through 
clock synchronization. 

Solutions proposed in the literature on 
clock synchronization take either a soft¬ 
ware or a hardware approach. The software 
approach is flexible and economical, but 
additional messages must be exchanged 
solely for synchronization. 1 ' 4 Because they 
depend on message exchanges, the worst- 
case skews guaranteed by most of these 
solutions are greater than the difference 
between the maximum and minimum mes¬ 
sage transit delay between any two nodes in 
the system. The hardware approach, on the 
other hand, uses special hardware at each 
node to achieve a tight synchronization with 
minimal time overhead. 5 ' 8 However, the cost 
of additional hardware precludes this ap¬ 
proach in large distributed systems unless a 
very tight synchronization is essential. 
Hardware solutions also require a separate 
network of clocks that is different from the 
interconnection network between the nodes 
of the distributed system. 6 

Because of these limitations in the soft¬ 
ware and hardware approaches, research¬ 
ers have begun investigating a hybrid ap¬ 
proach. A hardware-assisted software 
synchronization scheme has been proposed 
that strikes a balance between the hard¬ 
ware requirement at each node and the 
clock skews attainable. 9 Another recently 
proposed approach is probabilistic clock 
synchronization, in which the worst-case 
skews can be made as small as desired. 10 


However, depending on the desired worst- 
case skews, there is a nonzero probability 
of loss of synchronization. Also, this ap¬ 
proach may induce very high traffic to the 
system. 

This article compares and contrasts ex¬ 
isting fault-tolerant clock synchronization 
algorithms. The worst-case clock skews 
guaranteed by representative algorithms 
are compared, along with other important 
aspects such as time, message, and cost 
overhead imposed by the algorithms. 
Special emphasis is given to more recent 
developments such as hardware-assisted 
software synchronization, probabilistic 
clock synchronization, and algorithms for 
synchronizing large, partially connected 
distributed systems. 

Preliminary concepts 

First we define some of the concepts 
common to most clock synchronization 
algorithms and introduce the notation that 
will be used throughout the article (see 
sidebar on next page). We begin with the 
notion of a clock. 

Definition 1: Time that is directly ob¬ 
servable in some particular clock is called 
its clock time. This contrasts with the 
term real time, which is measured in an 
assumed Newtonian time frame that is 
not directly observable. 

It is convenient to define the local clock 


at a node as a mapping from real time to 
clock time. In other words, let C be a 
mapping from real time to clock time, then 
C(t) = T means that when the real time is t, 
the clock time at a particular node is T. We 
adopt the convention of using lowercase 
letters to denote quantities that represent 
real time and uppercase letters to denote 
quantities that represent clock time. Figure 
2 illustrates the concept of a clock function/ 
mapping. A perfect clock is one in which a 
unit of clock time elapses for every unit of 
real time. If more or less than one unit of 
clock time elapses for every unit of real 
time, the clock is said to be fast or slow, 
respectively. 

Since a properly functioning clock is a 
monotonic increasing function, its inverse 
function is well defined. Let c(T) = C~ l (T) 
= t denote this inverse function. In the 
literature some of the results in clock 
synchronization are formulated using the 
clock function, while others are formulat¬ 
ed using the inverse function. We will use 
subscripts to distinguish between the dif¬ 
ferent clocks in the system. For example, 
C p (r) will denote the clock at node p, and 
C a (0 the clock at node q. A clock is con¬ 
sidered nonfaulty if there is a bound on the 
amount of deviation from real time for any 
given finite time interval. In other words, 
even nonfaulty clocks do not always main¬ 
tain perfect time. 

Definition 2: A clock c is said to be 

nonfaulty during the real-time interval 

ffi, Ul if it is a monotonic, differentiable 
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function on [T h T 2 ] where c(Tj) = f ; , i = 
1,2, and for all [T h T 2 ] 

\dc(T) |'p 
I dT I 2 


for some constant p. The constant p is said 
to be the drift rate of the nonfaulty clock. 

Instead of the above definition, some 
synchronization algorithms are defined 
using one of the following near-equivalent 
definitions for a nonfaulty clock: 


Definition 2a: A clock c is said to be 
nonfaulty if there exists a constant p 2 
such that for t\ and t 2 


1-P2 


C(f 2 )-C(ti) 
ti-t i 


Pi 


Definition 2b: A clock c is said to be 
nonfaulty if there exists a constant p 3 
such that for t x and t 2 

1 ,C(t 2 )-C(D) .. 

- < - < 1 + p 3 

1+P3 h-h 


The near equivalence of these defini¬ 
tions follows from the Taylor series ex¬ 
pansion of (1 + p) -1 : 

(1 + p)-> = 1 - p + p 2 - p 3 + p 4 - ... 

For a typical value of p = 10 -6 , the second- 
order and high-order terms can be ignored, 
thus implying p 2 = P3 = p/2. 

The above notion of a clock does not 
imply any particular implementation. In 
fact, some synchronization algorithms deal 
with hardware clocks, while others deal 
with logical clocks. Hardware clocks are 
the actual clock pulses that control circuitry 
timing; logical clocks are values derived 
from hardware clocks. For instance, a log¬ 
ical clock might be the value of a counter 
that is incremented once every predeter¬ 
mined number of pulses of the hardware 
clock. In either case, we can talk about 
synchronization in terms of the abstract 
notion of the mapping function from clock 
time to real time. The main difference will 
be in the granularity, or skew, of synchro¬ 
nization. 


Definition 3: Two clocks c , and c 2 are said 
to be S-synchronized at a clock time T if 
and only if I c x (T) - c 2 (T) I < 8. A set of 
clocks are said to be well synchronized if 
and only if any two nonfaulty clocks in 
this set are 8-synchronized for some 
specified constant 8. 


Notations used in this article 

c p (t) Clock time at node p when the real time is t 
Cp{T) Real time when the clock time at node p is T 
p Maximum drift rate of all clocks in the system 

8 Maximum skew between any two nonfaulty clocks in the system 

e Upper bound on the read error 
m Maximum number of faulty clocks in the system 
N Total number of clocks in the system 
R Resynchronization interval 

U Upper bound on message transit delay 

A qp Node p's perception of its skew with respect to clock at node q 


Because of the nonzero drift rates of all 
clocks, a set of clocks does not remain well 
synchronized without some periodic re¬ 
synchronization. This means that the nodes 
of a distributed system must periodically 
resynchronize their local clocks to main¬ 
tain a global time base across the entire 
system. Synchronization requires each node 
to read the other nodes’ clock values. The 
actual mechanism used by a node to read 
other clocks differs from one algorithm to 
another. In hardware algorithms the clock 
signal from each of the other nodes (or an 
appropriate subset of nodes) is an input to 
the synchronization circuitry at each node. 
In software algorithms each node either 
broadcasts its clock value to all nodes at 
specified times or sends its clock value 
individually to requesting nodes. 

Regardless of the actual reading mech¬ 
anism, a node can obtain only an approx¬ 
imate view of its skew with respect to other 
nodes in the system. Errors occur mainly 
because it takes a finite and unpredictable 
amount of time to deliver a clock signal or 
a clock message from one node to another. 
In hardware algorithms, errors are due 
mainly to the unpredictable propagation 
delays for clock signals, whereas in soft¬ 
ware algorithms errors are due to variation 
in the message transit delays. Most of the 
synchronization algorithms discussed in 
this article are based on the assumption 
that if two nodes are nonfaulty, the error in 



reading each other’s clock is bounded. Since 
the actual errors that occur differ from one 
algorithm to another, we will discuss them 
further as we describe each algorithm. 

The time at which a node decides to read 
the clocks at other nodes also depends on 
the algorithm under consideration. In 
hardware algorithms, synchronization cir¬ 
cuitry continuously monitors the frequen¬ 
cy and phase of all clocks. On the basis of 
the input signals, the circuitry also updates 
the local clock continuously. Hardware 
algorithms can therefore be classified as 
continuous-update algorithms. Software 
synchronization algorithms, on the other 
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hand, are usually discrete-update algo¬ 
rithms; that is, correction to a local clock is 
computed at discrete time intervals. How¬ 
ever, software algorithms may differ in the 
way they apply this correction to the local 
clock. In some software synchronization 
algorithms the correction is applied in¬ 
stantaneously, whereas in others it is spread 
over a time interval. 

The time at which the correction is 
computed is determined by each node on 
the basis of its own clock. The time interval 
between successive corrections is called 
the resynchronization interval, denoted R, 
and is usually a constant known to all 
nodes. If T (0) denotes the time at which the 
system began its operation, then the time of 
the /th resynchronization is + iR. 

The time interval R <r> = [P f \ l< i+ '>] is often 
called the /th resynchronization interval. 
In discrete-update algorithms, we can view 
the local clock of a node as a series of 
functions, one for each resynchronization 
interval. That is, the clock at node p in the 
(/ + l)th resynchronization is given by 

4‘* l HT) = c«>\T + !$>) 

where represents the change in/j’s clock 
since the start of the system. 

Software 

synchronization 

The basic idea of software synchroniza¬ 
tion algorithms is that each node has a 
logical clock that provides a time base for 
all activities on that node. This logical 
clock is derived from the hardware clock 
on that node, though it usually has a much 
larger granularity than the hardware clock. 
The algorithm executed by each node for 
synchronizing the logical clocks can be 
viewed as a clock process invoked at the 
end of every resynchronization interval. 
This clock process is responsible for peri¬ 
odically reading the clock values at other 
nodes and then adjusting the correspond¬ 
ing local clock value. 

Informally, any software synchronization 
algorithm must satisfy the following two 
conditions: 

Agreement: The skew between all non- 

faulty clocks in the system is bounded. 

Accuracy: The logical clocks keep up 

with real time. 

The first condition states that there is a 
consistent view of time across all nodes in 
the system. The second condition states 


that this view of time is consistent with 
what is happening in the environment. The 
synchronization algorithms differ in the 
way these two conditions are specified, as 
well as in the way the clock processes read 
the clock values at other nodes. In some 
algorithms, a clock process requests and 
receives a clock value from each of the 
other nodes, while in other algorithms the 
clock process broadcasts its local clock 
value when it thinks it is time for a resyn¬ 
chronization. The other nodes receive the 
broadcast message and use the clock value 
for correcting themselves at a later time. In 
either case, the skew perceived by a receiv¬ 
ing clock process differs from the actual 
skew that exists between the two clocks, 
because of the errors in reading the clocks. 
These errors are due mainly to unpredict¬ 
able variation in the communication delay 
between the two nodes. This notion is 
formalized in the following discussion. 

Let p and q be any two nonfaulty nodes 
in the system. Let T be the clock time of 
node q when the clock process at node q 
initiates a broadcast of the local clock value. 
In other words, let the clock process at 
node q initiate a broadcast of the local 
clock value at real time c q (T). This mes¬ 
sage will reach p after some time delay, say 
Q. That is, the broadcast message is de¬ 
livered to node p at real time c q (T) + Q. At 
that instant, the clock times at nodes p and 
q are C p (c q (T) + Q) and C q (c q (T) + Q), re¬ 
spectively. That is, the actual skew exist¬ 
ing between p and q at the instant when p 
receives this message is given by C q (c q (T) 
+ Q)~ C p (c q (T) + Q). However, node p has 
no way of determining C q (c q (T) + Q) ex¬ 
actly. The best it can do is estimate the 
delay Q by, say, 1 + p 3 g, and compute the 
skew as follows: 

\p = T+ Q-C„(c q (T) + Q). 

This means that the error in the perceived 

e qP = T+ Q-C q {c q (D + Q). 

This error is small if we can obtain a good 
estimate of the communication delay and if 
the clock drifts of p and q are comparable, 
especially during the communication delay. 
All synchronization algorithms discussed 
in this article are based on the assumption 
that if p and q are nonfaulty, then e qp is 
bounded. 

From the above discussion we can con¬ 
clude that the read error is not a serious 
problem if the algorithm is used to syn¬ 
chronize a fully connected system. How¬ 


ever, it can be a serious limitation in future 
distributed systems because system size is 
increasing, and it is difficult to fully con¬ 
nect all the nodes in a large distributed 
system. This problem has been specifically 
addressed by some of the recent algo¬ 
rithms. 9 ' 10 

Software synchronization algorithms can 
be classified as convergence algorithms 
with averaging, convergence algorithms 
without averaging, or consistency algo¬ 
rithms (see Figure 3). The leaves of the tree 
in Figure 3 are the representative software 
synchronization algorithms surveyed in this 
article. (For additional reading refer to 
Schneider. 11 ) 

Convergence-averaging algorithms. 

Convergence-averaging algorithms are 
based on the following idea: The clock 
process at each node broadcasts a “resync” 
message when the local time equals T {0) + 
iR - S for some integer i and a parameter S 
to be determined by the algorithm. After 
broadcasting the clock value, the clock 
process waits for S time units. During this 
waiting period, the clock process collects 
the resync messages broadcast by other 
nodes. For each resync message, the clock 
process records the time, according to its 
clock, when the message was received. At 
the end of the waiting period, the clock 
process estimates the skew of its clock 
with respect to each of the other nodes on 
the basis of the times at which it received 
resync messages. It then computes a fault- 
tolerant average of the estimated skews 
and uses it to correct the local clock before 
the start of the next resynchronization in¬ 
terval. 

The convergence-averaging algorithms 
proposed in the literature differ mainly in 
the fault-tolerant averaging function used 
to compute the correction. In algorithm 
CNV, 1 each node uses the arithmetic mean 
of the estimated skews as its correction. 
However, to limit the impact of faulty 
clocks on the mean, the estimated skew 
with respect to each node is compared 
against a threshold, and skews greater than 
the threshold are set to zero before comput¬ 
ing the mean. In contrast, with the algo¬ 
rithm in Lundelius-Welch and Lynch 3 
(henceforth referred to as algorithm LL), 
each node limits the impact of faulty clocks 
by first discarding the m highest and m 
lowest estimated skews and then using the 
midpoint of the remaining skews as its 
correction, where m is the maximum num¬ 
ber of faulty clocks to be tolerated. 

One main limitation of the convergence¬ 
averaging algorithms is that they are in- 
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Figure 3. Classification of software synchronization algorithms. 


tended for a fully connected network of 
nodes. As a result, the algorithms are not 
easily scalable. In addition, they all require 
known upper bounds on clock read error 
and initial synchronization of the clocks. 
The need for initial synchronization is not 
a serious problem, because there are sever¬ 
al algorithms to ensure it. 3 However, the 
assumption about the bound on the clock 
read error is a serious problem because the 
worst-case skews guaranteed by these con¬ 
vergence-averaging algorithms are usually 
greater than the bound on the read error. 

In addition to the read error, the worst- 
case skews depend on the time interval 
between the resynchronizations, the clock 
drift rates, the number of faults to be toler¬ 
ated, the total number of clocks in the 
system, and the duration of the time inter¬ 
val during which the clock processes read 
the clock values at other nodes. However, 
among all these factors, the read error has 
the greatest impact on the worst-case skew. 
Lamport and Melliar-Smith 1 show the worst- 
case skew for algorithm CNV to be 

max ( [N/N - 3mJ[2e + p(R + 2[(V - m)l 
N]S)],8 0 + pR} 

where 5 0 is the maximum skew after the 
initial synchronization, N is the total num¬ 
ber of clocks in the system, m is the max¬ 
imum number of faults to be tolerated, S is 
the duration of the time interval during 
which clock processes read the clock val¬ 
ues at other nodes, and e is the assumed 
bound on the read error. Similarly, in Lun- 
delius-Welch and Lynch 3 the worst-case 
skew of algorithm LL was shown to be 

P + e + p(7P + [/+4e) + 4p2(2 + p)(P + 60 

where U is the maximum message transit 
delay between any two nodes in the system, 
e is such that U — 2e is the minimum mes¬ 
sage transit delay between any two nodes in 
the system, and P is roughly 4(e + pR). 

Since, typically, p is on the order of 
10 -6 , R is on the order of a few seconds, U 
and S are on the order of a few milliseconds, 
and e is on the order of a few microseconds, 
pU « e and pe « e. Dropping the higher 
order terms, the worst-case skew of algo¬ 
rithm CNV 1 is approximately 

[N/(N - 3m)](2e + pR) 

while the worst-case skew of the algorithm 
LL 3 is 5e + 4 pR. Superficially, this seems 
to indicate that algorithm LL is better than 
algorithm CNV. However, because of the 
nature of the clock-reading process, the 


read error in algorithm LL is much larger 
than that in algorithm CNV, and the worst- 
case skews of the two algorithms are actu¬ 
ally comparable. This is an example of the 
many pitfalls encountered in comparing 
clock synchronization algorithms. 

Convergence-nonaveraging algo¬ 
rithms. Like algorithms CNV and LL, 
convergence-nonaveraging algorithms are 
discrete-update algorithms. However, they 
do not use the principle of averaging to 
synchronize nonfaulty clocks. Instead, each 
node periodically seeks to be the system 
synchronizer. All the nonfaulty nodes know 
the time at which the nodes try to become 
the system synchronizer. If all the nodes 
are nonfaulty, only one becomes the syn¬ 
chronizer. If the synchronizer fails, the 
algorithm is designed so that the remaining 
nonfaulty nodes effectively take over and 
synchronize despite the faulty synchroniz¬ 
er’s erroneous behavior. 

Like convergence-averaging algorithms, 
convergence-nonaveraging algorithms also 
require initial synchronization and a bound 
on the maximum message transit delay in 
the system. However, convergence-non¬ 
averaging algorithms do not require a fully 
connected network of nodes. Instead, they 
require an authentication mechanism that 
the nodes can use to encode their messages 
in such a way that no other node can gen¬ 
erate the same message or alter the mes¬ 
sage without detection. This can be achieved 
by using either digital signatures 2 or an 
appropriate broadcast algorithm. 4 As long 
as all nonfaulty nodes can communicate 
with each other, the convergence-nonaver¬ 


aging algorithms will ensure that they are 
synchronized. However, the worst-case 
skew between the nonfaulty clocks is a 
strong function of the maximum message 
transit delay in the system. This means that 
as the connectivity decreases, the worst- 
case skew guaranteed by the algorithms 
increases. 

In convergence-nonaveraging algo¬ 
rithms, a node resynchronizes its clock 
either when its local clock reaches the time 
for the next resynchronization or when it 
receives a signed message from other nodes 
indicating that they have resynchronized 
their clocks. To prevent faulty nodes from 
falsely triggering a resynchronization, each 
node performs a validity check before re¬ 
acting to any message. The validity check’s 
exact nature depends on the algorithm. In 
Halpern et al., 2 a node considers a resyn¬ 
chronization message to be valid and hence 
is willing to resynchronize even before its 
clock reaches the time for the next resyn¬ 
chronization only if 

(1) all signatures in the message are 
valid, indicating that the message is 
authentic; 

(2) the time stamp on the message cor¬ 
responds to the time for the next 
resynchronization — that is, for the 
ith resynchronization, the message 
should have a time stamp T® = P 0) + 
iR; and 

(3) the message is received sufficiently 
close to the time for resynchroniza¬ 
tion — that is, a message with k 
distinct signatures should be received 
when the local time lies in the inter- 
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val (T® - kU, T®j, where U is the 
maximum message transit delay be¬ 
tween any pair of nodes in the sys- 

In Srikanth and Toueg, 4 however, a node 
considers all resynchronization messages 
suspicious. Therefore, a node is willing to 
resynchronize before its clock reaches the 
time for the next resynchronization only if 
it receives a message from m + 1 other nodes 
indicating that they have resynchronized. 
This is done to ensure that at least one 
nonfaulty node’s clock has reached the 
time for resynchronization. 

The main limitation of convergence¬ 
nonaveraging algorithms is that the worst- 
case skew is greater than the maximum 
message transit delay between any pair of 
nodes. For instance, the worst-case skews 
of the algorithms in Halpern et al. 2 and 
Srikanth and Toueg 4 are (1 + p)U + p(2 + 
p)R and \R(\ + p) + U][p(2 + p)/( 1 + p)] 
+ U( 1 + p), respectively. Since all the terms 
are positive, the worst-case skew is great¬ 
er than the maximum message transit de¬ 
lay, U, in both algorithms. Since U can be 
on the order of tens of milliseconds, espe¬ 
cially in a large, partially connected dis¬ 
tributed system, the worst-case skews 
offered by these algorithms are also on 
the order of tens of milliseconds, which 
may not be acceptable in many applica- 

One of the unique features in Srikanth 
and Toueg’s algorithm is that the accuracy 
of the logical clocks is guaranteed to be 
optimal in the sense that the drift rate of the 
logical clocks is the same as the drift rate of 
the underlying hardware clocks. This is not 
necessarily the case with other software 
clock synchronization algorithms, where 
the logical clocks are guaranteed only to be 
within a linear envelope of the hardware 
clocks. Furthermore, in contrast to the al¬ 
gorithm in Halpern et al., Srikanth and 
Toueg ’ s algorithm does not require a clock 
value to be sent in a resynchronization 
message. This characteristic can be used 
to eliminate some of the possible failure 
modes observed in a clock synchroniza¬ 
tion scheme. 

Consistency algorithms. Consistency- 
based algorithms use a completely differ¬ 
ent principle than convergence-based al¬ 
gorithms. They treat clock values as data 
and try to ensure agreement by using an 
interactive consistency algorithm. 12 This 
is a distributed algorithm that ensures 
agreement among nonfaulty nodes on the 
private value of a designated sender node 
through a series of message exchanges. By 


“agreement” we mean the following two 
conditions are satisfied: 

(1) All nonfaulty nodes agree on the 
sender’s private value. 

(2) If the sender is nonfaulty, the value 
agreed on by the nonfaulty nodes equals 
the sender’s private value. 

Note that nonfaulty nodes must agree on 
the sender’s private value regardless of 
whether the sender is faulty or not. How¬ 
ever, if the sender is faulty, the value agreed 
on by the nonfaulty nodes need not equal 
the sender’s private value. 

With consistency-based algorithms, at 
the end of every resynchronization interval 
each node treats its local time as a private 
value and uses an interactive consistency 
algorithm to convey this value to other 
nodes. From the clock values thus obtained 
from all the other nodes, each node computes 
an estimate of the skew with respect to 
every other node. Each node then uses the 
median skew to correct the local clock at 
the start of the next resynchronization in- 

Like convergence algorithms, consis¬ 
tency-based algorithms require a bound on 
the read error. Read errors occur in these 
algorithms because there can be a slight 
difference between the times at which two 
nodes, say p and q, decide on the clock value 
of another node, say r. Consequently, al¬ 
though p and q will agree on the clock value 
of r, the estimate of the skew they compute 
between their own clocks and r’s clock 
might be slightly different. In addition to a 
bound on the read error, consistency-based 
algorithms also require certain conditions 
for correctly executing an interactive con¬ 
sistency algorithm. These requirements 
include conditions on the minimum num¬ 
ber of nodes, sufficient connectivity, and a 
bound on the message transit delay. Lam¬ 
port, Shostak, and Pease provide more 
details on these requirements. 12 

Note that these algorithms require no 
assumption about initial synchronization. 
Nor do they require a direct connection 
between all the nodes, although the algo¬ 
rithms described by Lamport and Melliar- 
Smith 1 do require such a connection. 

The following example should clarify 
the basic idea of these algorithms. Consid¬ 
er a four-node system with a maximum of 
one Byzantine fault. In an interactive 
consistency algorithm, 12 a node p would 
convey its private value to other nodes 
using the following scheme: Node p would 
send its value to every other node, which in 
turn would relay the value to the two re¬ 
maining nodes. That is, each node would 


receive three “copies” of p's value: one 
directly from p and the other two from the 
other two nodes. Each node would then 
estimate p’s value to be the median of the 
values in the three copies. This scheme can 
be modified for clock synchronization by 
letting each node independently use the 
interactive consistency algorithm to convey 
its clock value to other nodes. At the end of 
four applications of the interactive con¬ 
sistency algorithm (one for each node), the 
local clock at each node could be adjusted 
to equal the median of the other nodes’ 
clock values. 

This clock synchronization scheme can 
be further extended to situations with more 
than one Byzantine fault, just like the inter¬ 
active consistency algorithm. 12 However, 
this will require at least m + 1 rounds of 
message exchange, where m is the maxi¬ 
mum number of faults to be tolerated, and 
this implies more overhead. The worst- 
case skew guaranteed by consistency-based 
algorithms, however, is usually smaller 
than those guaranteed by the convergence- 
based algorithms. For example, if the total 
number of clocks in the system equals 3 m 
+ 1, then the worst-case skew of algorithm 
COM in Lamport and Melliar-Smith was 
shown to be (6 m + 4)e + (4m + 3 )pS + pR 
as opposed to (6m + 2)e + (4m + 2)pS + (3m 
+ 1 )pR for algorithm CNV, 1 where e, S, and 
R are as described earlier under “Conver¬ 
gence-averaging algorithms.” 

The number of messages required for 
consistency-based algorithms can be re¬ 
duced by using digital signatures to au¬ 
thenticate the messages. This is true of 
algorithm CSM in Lamport and Melliar- 
Smith. Algorithms with authentication re¬ 
quire fewer messages and fewer nodes to 
tolerate a given number of faults. They also 
achieve a tighter skew than algorithms that 
do not use authentication. 

Probabilistic synchronization. The 

main limitation of the algorithms discussed 
above is that the worst-case skew depends 
heavily on the maximum read error. This 
can be a serious problem in future distrib¬ 
uted systems because read errors are likely 
to increase with system size. To remedy 
this problem, Cristian proposed a proba¬ 
bilistic synchronization scheme in which 
the worst-case skews can be made as small 
as desired. 10 However, the overhead im¬ 
posed by the synchronization algorithm 
increases drastically as we reduce the skew. 
Furthermore, unlike other algorithms we 
have discussed, this algorithm does not 
guarantee synchronization with probabili¬ 
ty one. In fact, there is a nonzero probabil- 
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ity of loss of synchronization, and this 
probability increases with a decrease in the 
desired skew. 

Cristian’s idea is to assume that the 
probability distribution of message transit 
delay is known and let each node make 
several attempts to read the other clocks. 
After each attempt, the node can calculate 
the maximum error that might occur if the 
clock value obtained in that attempt were 
used to determine the correction. By retrying 
often enough, a node can read the other 
clocks to any given precision with prob¬ 
ability as close to one as desired. This 
scheme is particularly suitable for systems 
having a master-slave arrangement in 
which one clock has been designated or 
elected master and the other clocks act as 
slaves. 

More specifically, each node periodical¬ 
ly sends a message to the master node 
requesting its clock value. When the mas¬ 
ter receives this request, it responds with a 
message saying “The time is 77’ When the 
response reaches the requesting node, it 
calculates the total round trip delay ac¬ 
cording to its own clock. If D is the round 
trip delay as measured by a node p, and if 
q is the master node, then Cristian proved 
that if nodes p and q are nonfaulty, the local 
time at node q when p receives the re¬ 
sponse message lies in the interval 

IT + u mi „{ l -p), 

T+D(\+2p)-U mm (\+p)] 

where U min is the minimum message transit 
delay between p and q. Therefore, the 
maximum read error is D( 1 + 2p) - 2U min . 

It follows from this result that if the 
round trip delay is small (close to 2 U min ), 
then so is the read error. Cristian’s algorithm 
uses this observation to limit the read error. 
Each node is allowed to read the master’s 
clock repeatedly until the round trip delay 
is such that the maximum read error is 
below a given threshold. Once a node reads 
the master’s clock to the desired precision, 
it sets its clock to that value. 

One limitation of this approach is the 
need to restrict the number of read attempts, 
since these are directly related to the 
overhead imposed by the algorithm. This 
implies that a node may not always be able 
to read the master’s clock to the desired 
precision and hence could result in loss of 
synchronization. A second limitation is 
that it is not fault tolerant, since it is not 
easy to detect the master’s failure. Fur¬ 
thermore, algorithms to designate or elect 
a new master are fairly complex and time- 
consuming. 


Hardware 

synchronization 

The principle of hardware synchroniza¬ 
tion algorithms is that of a phase-locked 
loop. The hardware clock at each node is an 
output of the voltage-controlled oscillator. 
The voltage applied to the oscillator comes 
from a phase detector whose output is 
proportional to the phase error between the 
phase of its clock (the output of the voltage- 
controlled oscillator it is controlling) and a 
reference signal generated by using the 
other clocks in the system. Thus, by ad¬ 
justing the frequency of each individual 
clock to the reference signal, the clocks can 
always be kept in lock-step with respect to 
one another. 

Algorithms. One of the first hardware 
synchronization algorithms resilient to 
Byzantine faults was proposed originally 
by T.B. Smith. This algorithm was devel¬ 
oped to synchronize the processors of the 
fault-tolerant multiprocessor (FTMP). 13 The 
FTMP uses only four clocks and was ex¬ 
pected to tolerate a maximum of one Byz¬ 
antine fault, so Smith’s algorithm was 
specifically developed for that situation. In 
the algorithm, each clock observes the other 
three clocks continuously and determines 
its phase difference with each of them. 
These phase differences are arranged in an 
ascending order, and the clock corre¬ 
sponding to the median phase difference is 
selected as the reference signal. Each clock 
uses a phase-locked loop to synchronize 
itself with the reference signal it selected. 

The worst-case skew in this algorithm 
depends on the characteristics of the phase- 
locked loop. Smith did not characterize 
this worst-case skew, but experimental 
results on the FTMP have shown that the 
skews are around 50 nanoseconds. This 
should be compared with the skews in the 
software synchronization algorithms, which 
are on the order of microseconds. Surpris¬ 
ingly, this algorithm does not easily gen¬ 
eralize to a situation in which more than 
one Byzantine fault must be tolerated. This 
is because with a median select algorithm 
it is possible for Byzantine failures to par¬ 
tition the set of clocks into two or more 
separate “cliques” that are internally syn¬ 
chronized but are not synchronized with 
other cliques. 

As an illustration, consider a system of 
seven clocks. Such a system should be able 
to mask the failure of two clocks. Suppose 
that the five nonfaulty nodes (clocks) are 
named a, b, c, d, and e and the faulty nodes 


(clocks) are named x and y. If the trans¬ 
mission delays between clocks are negli¬ 
gible, then the order of arrival of the clock 
signals from the nonfaulty nodes should be 
the same at all the nodes. If the faulty 
clocks behave erratically, their order may 
be seen differently by different nodes. 
Consider the following ordering of signals 
as seen by the various nodes in the system: 

Order seen by a: xyabcde 
Order seen by b: xyabcde 
Order seen bye: a b c d e xy 
Order seen by d: a b c d e xy 
Order seen bye: a b c d e xy 

Now suppose each node uses the median 
select algorithm to select a reference signal 
to synchronize its own clock. In the above 
example, this would mean that each node 
selects the third clock, not counting its own, 
as the reference signal; that is, nodes a, b, 
c, d, and e will synchronize to nodes b, a, d, 
c, and c, respectively. As a result, there are 
two nonsynchronizing cliques, [a, b) and 
{c, d, e (. By nonsynchronizing cliques we 
mean that a and b are synchronized to each 
other and c, d, and e are synchronized to each 
other, but there is nothing to prevent a and 
b from drifting far apart from c, d, and e. 

To overcome this problem, Krishna, Shin, 
and Butler proposed that each node p use 
the f p (N, m)th clock signal as the reference 
signal instead of the median signal, where 


f p (N,m) = { 


and where N is the total number of clocks, 
m is the maximum number of faults to be 
tolerated, and A p is the position of node p in 
the perceived order of the arriving clock 
signals at node p. They showed that if N> 
3m + 1, then this function for selecting the 
reference signal will ensure that all the 
nonfaulty nodes remain synchronized re¬ 
gardless of how the faulty nodes behave. 5 

For the situation above, N = l,m = 2, and 


4 ( 7 , 2 )* 


4 if A p < 5 
3 if Ap > 5 


Thus, a synchronizes to b, b synchronizes 
to c, c synchronizes to e, d synchronizes to 
e, and e synchronizes to c. This sequence of 
synchronization among the nodes results 
in a single clique containing all five non¬ 
faulty nodes. 

The problem with Krishna, Shin, and 
Butler’s scheme is that selection of the 
reference signal is based on the position of 
the local clock in the perceived sequence 
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Figure 4. Percentage of reduction over a fully connected network versus system 
size. 


of the incoming clock signals. This com¬ 
plicates the hardware at each node because 
the hardware must order the incoming clock 
signals and dynamically choose a reference 
signal by identifying the local clock’s po¬ 
sition in the ordered sequence. To overcome 
this problem, Vasanthavada and Marinos 
proposed a slight variation of the above 
scheme, using two reference signals instead 
of one. 8 

In their scheme it is not necessary to 
generate the complete sequence of all in¬ 
coming signals. Instead, it is sufficient to 
identify the (m + l)th and the (N-m - l)th 
clocks in the temporal sequence. This is 
easy to do in hardware because we can 
count the clock signals that have arrived 
and record the identity of the (m + l)th and 
the (IV - m - l)th clock signals. The aver¬ 
age phase difference of the local clock with 
respect to these two clock signals is used to 
correct the local clock in the subsequent 
cycles. 

Eliminating major limitations in 
hardware synchronization. The main 
advantage of the above hardware syn¬ 
chronization algorithms is that the worst- 
case skews are several orders of magnitude 
smaller than those in software synchroni¬ 
zation algorithms. However, these hardware 
synchronization algorithms have two ma¬ 
jor limitations. The first is that the hardware 
synchronization algorithms as described 
above require a fully connected network of 
clocks. Because of the many interconnec¬ 


tions in a fully connected network, this 
requirement means that the reliability of 
synchronization would be determined by 
the failure rates of these interconnections 
rather than by the failure rate of the clocks. 
Furthermore, the large number of intercon¬ 
nections would cause problems of fan-in 
and fan-out. 

The second limitation is that the above 
hardware synchronization algorithms are 
based on the assumption that the trans¬ 
mission delays are negligible compared 
with other parameters relevant to the algo¬ 
rithms. In a large system, the physical sep¬ 
aration between a pair of clocks can be 
enough to result in non-negligible trans¬ 
mission delays. A significant difference in 
the transmission delays between two pairs 
of nonfaulty clocks can change the order in 
which a nonfaulty clock perceives other 
nonfaulty clocks and thus affect the selection 
of the reference signal. 

These two limitations can be eliminated 
from any of the above algorithms with the 
help of the recent developments surveyed 
below. 

Interconnection problem. Shin and Ra- 
manathan recently proposed an intercon¬ 
nection strategy for synchronizing a large 
distributed system using any of the above 
hardware synchronization algorithms. 6 
Their interconnection strategy requires only 
20-30 percent of the total number of in¬ 
terconnections in a fully connected network. 

The idea behind their strategy is to 


synchronize the clocks in the system at two 
different levels. The clocks are first parti¬ 
tioned into several clusters. Each clock 
then synchronizes itself not only with re¬ 
spect to all the clocks in its own cluster but 
also with one clock from each of the other 
clusters. As a result of this mutual coupling 
between the clusters, the clusters remain 
synchronized with respect to each other, 
and the system as a whole remains well 
synchronized. 

Shin and Ramanathan formulate the 
problem of partitioning the clocks into 
clusters as a small integer-programming 
problem. The objective is to minimize the 
total number of interconnections subject to 
the constraint that the fault tolerance re¬ 
quirement is satisfied. For each clock, the 
solution to the integer-programming 
problem identifies all other clocks that it 
should monitor. Shin and Ramanathan 6 
show that this interconnection strategy does 
not result in loss of synchronization and 
the worst-case skew increases by a factor 
of three as compared with the skew in a 
fully connected network of clocks. 

The reduction in the total number of 
interconnections over a fully connected 
network as a function of system size is 
shown in Figure 4. It follows from this plot 
that the percentage of reduction increases 
with system size; this is precisely the sit¬ 
uation in which the number of intercon¬ 
nections is a serious problem. 

Transmission delay problem. The ef¬ 
fects of transmission delay in phase-locked 
loops have been studied extensively in the 
communication area but not in the presence 
of Byzantine faults. Shin and Ramanathan 7 
show that it is easy to incorporate ideas 
from the communication area to take into 
account the presence of Byzantine faults 
and non-negligible transmission delays. 

Figure 5 illustrates their underlying idea 
and shows the hardware required at node i 
to determine the exact phase difference 
between its clock and the clock at node j. 
Instead of one phase detector for every 
node pair, as in other algorithms, this solu¬ 
tion requires two phase detectors and an 
averager. The inputs to the first phase de¬ 
tector, PD i, are the clock signals from nodes 
i and j. Since the clock signal from node j 
encounters a delay in reaching node i, the 
phase difference detected by PD, does not 
represent the true phase difference between 
the two clocks. 

The inputs to the second phase detector, 
PD 2 , are the clock signals from node j and 
the clock signal from node i that is returned 
from node j. In other words, the clock signal 
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that node j is monitoring is returned to node 
i to be compared with the signal from node 
j. Because of the transmission delays, the 
phase difference detected by PD 2 also does 
not represent the true phase difference be¬ 
tween the two clocks. However, Shin and 
Ramanathan prove that the average of the 
outputs of PD! and PD 2 , e tj , is proportional 
to the exact phase difference between the 
clocks at nodes i and j regardless of the 
transmission delays. 

This true phase difference can then be 
used for any hardware synchronization al¬ 
gorithm. The disadvantages of this approach 
are the need for two phase detectors instead 
of one and the doubling of the number of 
interconnections. However, when this so¬ 
lution is combined with Shin and Ra¬ 
manathan’s interconnection scheme, we 
get a viable solution even for a very large 
distributed system. 

Hybrid synchronization 

Earlier we noted that the main drawback 
of software synchronization algorithms is 
that the worst-case skews are at least as 
large as the variation in the message transit 
delay in the system. This can be a serious 
problem in a large distributed system be¬ 
cause this variation can be substantial. For 
example, in some systems worst-case mes¬ 
sage transit delays as large as 100 times the 
mean message transit delay have been ob¬ 
served. In other words, the worst-case skews 
in such systems would be at least this large 
if a software clock synchronization algo¬ 
rithm were adopted. At the other extreme, 
hardware algorithms achieve very tight 
skews with minimal overhead. The skews 
in hardware algorithms are typically on the 
order of tens of nanoseconds, 8 as opposed 
to tens of milliseconds in the software 
algorithms. However, the hardware schemes 
are prohibitively expensive, especially in 
large distributed systems. 

To remove the inherent limitations of 
both the hardware and software approaches, 
Ramanathan, Kandlur, and Shin recently 
proposed a hybrid synchronization scheme 
that strikes a balance between the clock 
skews attainable and the hardware require¬ 
ment. 9 Their scheme is particularly suitable 
for large, partially connected homogeneous 
distributed systems with point-to-point 
interconnection topologies such as hyper¬ 
cubes or meshes. 

This hybrid scheme is similar to algorithm 
CNV. 1 As in CNV, each node has a clock 
process that is responsible for maintaining 
the time on that node. At a specified time in 



Figure 5. Elimination of transmission delay effects. 


the resynchronization interval, a clock 
process broadcasts the local clock value to 
all other clock processes. The broadcast 
algorithm is such that all clock processes 
receive multiple copies of the clock mes¬ 
sage through node-disjoint paths. The 
number of copies used in the broadcast 
algorithm depends on the maximum num¬ 
ber of faults to be tolerated and the fault 
model for the system. When a clock pro¬ 
cess receives a clock message sent by some 
other clock process, it records the time 
(according to its local clock) at which the 
message was received. Then, in accordance 
with the broadcast algorithm, it relays the 
message to other clock processes. 

Before relaying the message, a clock 
process appends to the message the time 
elapsed (according to its own clock) since 
receipt of the message. At the end of the 
resynchronization interval, it computes the 
skews between the local clock and the 
clock of the source node for each copy it 
has received. The clock process then selects 
the (m + 1 )th largest value as an estimate of 
the skew between the two clocks. The av¬ 
erage of the estimated skews over all nodes 
is used as the correction to the local clock. 
As in CNV, a minimum of 3m + 1 nodes is 
required to tolerate m Byzantine faults. 

Ramanathan, Kandlur, and Shin’s algo¬ 
rithm has several advantages over the algo¬ 
rithms discussed earlier. First, the sending 
of clock values by different nodes occurs 
throughout the resynchronization interval 
rather than during the last S time units of 
the interval. For hypercube and mesh ar¬ 
chitectures, they show that the resynchro¬ 
nization interval in their algorithm is so 


large that there is at most one node broad¬ 
casting its clock value at any given time. 
This prevents abrupt degradation in the 
message delivery times, which occurs when 
all nodes in the system broadcast clock 
values almost simultaneously. Second, the 
only hardware requirement at each node is 
for time-stamping of clock messages. The 
third, and probably most important, advantage 
is that the worst-case skews are about two to 
three orders of magnitude tighter than the 
skews in software schemes. Furthermore, be¬ 
cause of the hardware support, the worst- 
case skews are insensitive to variations in 
message transit delay in the system. 

To compare the hybrid synchronization 
scheme with the various software and 
hardware synchronization schemes, con¬ 
sider the worst-case skew this algorithm 
guarantees. Ramanathan, Kandlur, and Shin 
show that this worst-case skew is 


g_ m f 2 (N-m)(E + 2pNU) + 2 m£ 
maX *■ (N - 3m) 

*dn%sMi*iu} 


where the notation is the same as that used 
for characterizing algorithm CNV under 
“Convergence-averaging algorithms.” The 
slight difference between the above ex¬ 
pression and the corresponding expression 
for algorithm CNV is that for algorithm 
CNV the read error e incorporated the ef¬ 
fects of message transit delays between 
any two of the system nodes. This is be¬ 
cause algorithm CNV was intended for a 
fully connected system in which the mes¬ 
sage transit delays are very small. In con- 
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trast, the algorithm in the hybrid scheme is 
intended for a partially connected system 
in which the message transit delay can be 
fairly large. Therefore, the effect of mes¬ 
sage transit delay ( U ) on the skew has been 
separated from the effect of other read 
errors (£). 

The key conclusion we can draw from 
the above expression is that the worst-case 
skew is not an explicit function of U as in 
most software synchronization algorithms 
but a function of p • U. As a result, for 
typical values of p = 10 -s and e = 20 mi¬ 
croseconds, Ramanathan, Kandlur, and Shin 
show that the worst-case skew in a 512- 
node hypercube with m = 2 is less than 200 
microseconds even when the maximum 
message transit delays are as large as 50 
milliseconds. These skews are still much 
larger than those achieved by hardware 
synchronization algorithms, but the cost of 
hardware synchronization for a system this 
large would be exorbitant. 


C lock synchronization is an impor¬ 
tant matter in any fault-tolerant dis¬ 
tributed system and has been ex¬ 
tensively studied in recent years. Unfortu¬ 
nately, the various solutions proposed are 
difficult to compare because they are pre¬ 
sented under different notations and as¬ 
sumptions. Additional difficulty arises be¬ 
cause of slight differences in the assumptions 
made by the different synchronization al¬ 
gorithms. In this article we classified and 
presented several software and hardware 
synchronization algorithms as well as a 
hybrid synchronization algorithm, all us¬ 
ing a consistent notation. We also identi¬ 
fied the assumptions each algorithm makes. 

Software algorithms require nodes to 
exchange and adjust their individual clock 
values periodically. Since the clock values 
are exchanged via message passing, the 
time overhead these algorithms impose can 
be substantial, especially if a tight synchro¬ 
nization is desired. They are therefore suitable 
for applications that can tolerate a loose 
synchronization between the system nodes. 

Hardware algorithms, on the other hand, 
use special hardware to ensure a very tight 
synchronization. Although the overhead 
they impose on the system is minimal, the 
hardware algorithms are too expensive to 
use for all but small systems. 

The hybrid scheme is cost-effective and 
achieves a reasonably tight synchroniza¬ 
tion. It is also suitable for synchronizing 
large, partially connected systems and hence 
is the most viable scheme for future dis¬ 
tributed systems. ■ 
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B uilt-in self-test techniques are 
gaining ground in the testing of 
logic circuits because they offer a 
cost-effective way to test high-density dig¬ 
ital devices. The basic philosophy behind 
the BIST technique is “let the hardware 
test itself’ — that is, enhance the func¬ 
tionality of a logic circuit to test itself. The 
BIST concept was first proposed for com¬ 
binational circuits, but it later found a quick 
application in the testing of such regular 
structures as random-access memories, 
read-only memories, and programmable 
logic arrays. 

In the early days of memory design, test 
procedures were developed in an ad hoc 
manner. The fault coverages of these ad 
hoc test procedures were limited and often 
indeterminable. This shortcoming, ac¬ 
knowledged by most researchers, motivated 
the introduction of such fault models as 
stuck-at faults, decoder faults, coupling 
faults, and pattern-sensitive faults. By and 
large, the fault models have been simple. 
Until recently, researchers did not develop 
models covering complex cell interactions, 
because they believed that long tests would 
be required to detect such faults. In con¬ 
ventional testing environments with exter¬ 
nal testers, the only tests thought practical 
for large RAMs were those having a linear 
relationship with the number of bits, N, in 
the RAM. Ironically, the larger the RAM, 
the more complex the fault model required 



An examination of 
BIST schemes 
indicates that 
approaches based on 
test architectures 
rather than on test 
algorithms are more 
versatile and will likely 
predominate in 
the future. 


to effectively model the variety of physical 
failures that could occur because of inter¬ 
ference between closely packed cells. 

In a BIST environment, relatively inex¬ 
pensive testers can perform functional test 
for testing RAMs. A BIST tester need only 
power up a chip, initiate the test signal, and 
read the chip’s status. Therefore, much 
longer tests providing higher fault cover¬ 
age without excessive cost can be applied. 

0018-9162/90/1000-0045$01.00 © 1990 IEEE 


The test time estimates in Table 1 (assum¬ 
ing a 10-megahertz clock) show that for 
large RAMs 0(/V 2 )-length tests may be 
unacceptable (an O (N a ) test means a test of 
length CN a , where C is a constant). Nev¬ 
ertheless, 0(A f3/2 )-length tests can be 
practical for memories of 4 megabits or 
larger, depending on the extent to which 
the memory’s internal organization can be 
exploited by the BIST logic. 

Judging by the current trends, memory 
size will continue to increase. As memories 
become larger, BIST becomes more of a 
necessity because of the high costs incurred 
by off-line testers for even 0(N) tests. 
Furthermore, even if the order of test length 
is moderately high, BIST techniques can 
bring down the effective test time by using 
such techniques as parallel testing and line¬ 
mode testing. 

Another motivation for BIST is that the 
BIST logic incorporated in a chip can be 
used for both manufacture testing and in- 
circuit testing. If the implemented algo¬ 
rithm’s test length is sufficiently small, the 
same BIST logic can even be used for 
testing RAMs during computer power-on, 
as part of the CPU’s self-test procedures. 
Current BIST implementations cannot, 
however, be used for testing when the chip 
contains useful data. 

Although BIST may still be a high-over- 
head concept (about 20 to 30 percent) for 
general integrated-circuit designs, it requires 
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Table 1. Test time for different test lengths and memory sizes (with a 10-mega- 
hertz clock). 


Test 

Length 

1 Mbit 

Memory Size 

4 Mbits 

16 Mbits 

A 

0.1 sec. 

0.4 sec. 

1.6 sec. 

A log A 

2.1 sec. 

9.2 sec. 

40.3 sec. 

A3/2 

1.8 min. 

14.3 min. 

1.9 hr. 

A 2 

30.5 hr. 

20.3 days 

325.8 days 


little overhead (less than 1 percent) for 
application in large RAMs, as a later sec¬ 
tion shows. Furthermore, recent develop¬ 
ments in very large scale integrated cir¬ 
cuitry allow moderately complex test 
algorithms to be built within a chip. 

In this context, the article has four major 
purposes: 

• to demonstrate that BIST is a viable 
solution to the problem of testing large 
memories, 

• to introduce the notion of generic test 
architectures suitable for implementing 
a wide variety of test algorithms, 

• to provide a taxonomy for test archi¬ 
tectures and use this taxonomy to cat¬ 
egorize BIST implementations, and 

• to survey the important BIST imple¬ 
mentations reported by universities and 
industry. 

A fair treatment of these four issues 
requires a discussion of the fault models 
and the test algorithms on which the BIST 
implementations are based. 

Fault models for RAMs 

Before discussing the important fault 
models, let’s consider how RAM chips are 
organized. A RAM chip consists of an 
array of memory cells, an address decoder, 
address and data registers, and a read/write 
logic. An A-bit RAM may be organized 
either as a single-bit output RAM (A-word 
x 1 -bit RAM) or as a £>bit output RAM (M- 
word X A;-bit RAM). Generally, an M-word 
x £-bit RAM is organized as k identical 
partitions. Each M-bit partition may itself 
be organized as /(/ > 1) two-dimensional 
arrays of m x n cells, such that M=lmn. Cells 
and their contents in each of these arrays 
are independent of the cells in other arrays. 
By assuming that no interaction can take 
place between cells of different arrays, we 
can model faults considering only a two- 
dimensional array. Therefore, we need only 


test each of these arrays completely, as 
opposed to testing the RAM as a single 
unit. The arrays can be tested sequentially 
or in parallel if the memory organization 
permits. The only restriction is that each 
array must be tested independently of the 
remaining arrays. 

A wide variety of physical failures can 
occur in the memory array, address decoder, 
and read/write logic, causing various fail¬ 
ures in the memory function. Their causes 
depend on such factors as component 
density, circuit layout, and manufacturing 
method. A number of fault models have 
been developed to capture the effects of 
physical failures in RAMs. In this section, 
we describe the important fault models 
relevant for the functional testing of RAMs 
using BIST. Faults not covered include 
soft faults such as transient faults and in¬ 
termittent faults. A recent survey paper on 
fault models and functional testing tech¬ 
niques for RAMs provides more detailed 
descriptions. 1 

Invariably, two assumptions have been 
used in the development of all fault models 
and test algorithms: the single-fault as¬ 
sumption and the nondestructive or fault- 
free read operations assumption. 

The single-fault assumption reduces the 
complexity of test procedures, which be¬ 
come unwieldy for most fault models if the 
test is designed to detect multiple faults. 
Tests that detect all single faults often 
detect most multiple faults. This justifies 
the use of the single-fault assumption. 

Th e, fault-free reads assumption has also 
been used for practical reasons. Test pro¬ 
cedures for RAMs often have some form of 
embedded checking experiment, that is, the 
application of a sequence of writes to bring 
the memory to a known state and the veri¬ 
fication of this state by reading the memo¬ 
ry cells. The test procedure becomes ex¬ 
tremely complex — and sometimes 
impossible — if the read operations are 
assumed to be faulty or destructive. In 
reality, however, most faults in the read/ 


write logic are easily detected because they 
result in catastrophic failures. 1 Simple tests 
can be derived and applied by an external 
tester in the final testing stages to detect 
noncatastrophic faults in the read/write 
logic. 

Stuck-at fault model. A memory cell is 
said to be stuck-at-1 (stuck-at-0) if its 
contents remain fixed at logic 1 (0), irre¬ 
spective of what is written into it. Stuck-at 
faults are also useful for modeling faults in 
other parts of the memory system, such as 
the decoder. 

Coupling fault model. A pair of mem¬ 
ory cells is said to be coupled if a transition 
in one of them changes the contents of the 
other cell from 0 to 1 or 1 to 0. Coupling 
faults are of two types. An idempotent 
coupling fault is one in which a transition 
in one cell forces the contents of another 
cell to a certain value (either 0 or 1), whereas 
an inversion coupling fault is one in which 
the transition causes an inversion in the 
contents of the second cell. Coupling faults 
could also exist between three or more 
cells. 

Pattern-sensitive fault model. A 

memory cell is said to have a pattern- 
sensitive fault if its state is altered by a 
pattern of 0’s and 1 ’s, 0 —> 1 transitions, 1 
—> 0 transitions, or both 0 —» 1 and 1 —> 0 
transitions in a group of other memory 
cells. The group of cells that influences the 
base cell’s behavior is called the neigh¬ 
borhood of the base cell. The problem of 
pattern sensitivity arises primarily from 
the high component densities of RAMs and 
the related effect of unwanted interacting 
signals. As RAM density increases, the 
cells become physically closer, and pattern- 
sensitive faults become the predominant 
faults. Moreover, other fault classes that 
affect the memory cells — shorts, stuck-at 
faults, and coupling faults—can be regarded 
as special types of pattern-sensitive faults. 

Testing a RAM for unrestricted pattern- 
sensitive faults is impractical, as it requires 
an 0{2 N ) test. 1 This fact has led researchers 
to consider restricted pattern-sensitive fault 
models in which the neighborhood size is 
small. Another restriction is on the positions 
in the array that a neighborhood is allowed 
to take. Often the neighborhood is allowed 
to take only the position that physically 
surrounds the base cell. Traditionally, the 
restricted neighborhoods considered are 
the five-cell and nine-cell physical neigh¬ 
borhoods. Figure la shows the five-cell 
physical neighborhood of a memory cell. 
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Figure 1. Different types of neighborhood: (a) a five-cell neighborhood; (b) a row/column neighborhood. 


Within the context of pattern sensitivity, 
different fault models have been proposed, 
based on the type of interaction between 
the cells. In the static-pattern-sensitive fault 
model, a cell is said to be faulty if its 
contents change when a certain pattern of 
0’s and 1 ’s exists in the neighborhood cells 
(that is, the pattern to which the cell is 
sensitive is static). A dynamic-pattern- 
sensitive fault is said to occur if the state of 
a cell changes because of a change in its 
neighborhood pattern. Researchers have 
also studied variations of these fault models, 
for example, those using active and passive 
neighborhoods. 1 

Row/column weight-sensitive fault 
model. The neighborhoods discussed so 
far for restricted pattern-sensitive faults 
are the physical neighborhoods of a cell. 
The row/column weight-sensitive fault 
model is based on the broader row/column 
neighborhood} The row (column) neigh¬ 
borhood of a cell consists of all the cells in 
the same row (column) but excluding the 
cell. It is related to the electrical neigh¬ 
borhood of a cell because cells of the same 
row share a common word line, and cells of 
the same column share a common bit line. 
The row/column neighborhood is much 
larger than the conventional five-cell and 
nine-cell physical neighborhoods described 
earlier. Row weight of a cell is the number 
of l’s in its row neighborhood; column 
weight is the number of l’s in its column 
neighborhood. 

Figure lb shows the row/column neigh¬ 
borhood, row weight, and column weight 
of a memory cell. The row/column weight- 
sensitive fault model is based on the obser¬ 


vation that the contents of a cell can be 
affected by the contents of cells in its row 
and column neighborhood. Interference 
could occur between cells of the same 
column or row, since these cells are electri¬ 
cally connected and share common ad¬ 
dressing and refresh circuitry. In the row/ 
column weight-sensitive fault model, a 
memory cell is said to be faulty if its con¬ 
tent is sensitive to any combination of row 
and column weights. 

Besides considering a larger neighbor¬ 
hood than the conventional five-cell and 
nine-cell neighborhoods, this fault model 
has an additional advantage: Tests that 
detect row/column weight-sensitive faults 
also detect most of the faults modeled by 
other fault models. Furthermore, weight- 
sensitive fault tests are also applicable for 
reconfigurable memory chips, whereas the 
five-cell-neighborhood pattern-sensitive 
fault tests are not. 

Faults in the decoder and read/write 
logic. Most faults occurring in the address 
decoder and the read/write logic can be 
mapped to faults in the memory cell array; 
that is, during tests of the memory cell 
array, they will behave as faults in the 
memory cell array. 1 A stuck-at fault in the 
read/write logic will appear as a large group 
of memory cells with a stuck-at fault. Thus, 
an algorithm that detects stuck-at faults in 
the memory array can easily detect this 
fault. The same arguments are valid for 
coupling faults. Similarly, faults in the 
address decoder can be modeled by faults 
in the memory array, so the decoder faults 
will be detected by tests for the memory 
cell array. 


Test algorithms and 
their fault coverages 

Over the years, several algorithms of 
different complexities have been developed 
to test RAMs. The early algorithms were 
ad hoc; the later algorithms were specifi¬ 
cally designed to detect faults from various 
fault models. Recently, random pattern 
testing has also been proposed for RAMs. 
In this article, we discuss only those test 
algorithms (ad hoc or specific) that have 
been applied (in original or modified form) 
for BIST implementation in either univer¬ 
sities or industry. 

All test algorithms consist of a sequence 
of writes and reads applied to the cells in 
the memory array. In our discussion, W, <— 
v denotes the operation “Write value v into 
cell i.” Similarly, R] ( = v) denotes the op¬ 
eration “Read cell i, with v as the expected 

Mscan test. Memory scan is a trivial test 
procedure developed in an ad hoc manner. 
The Mscan test writes each cell, first with 
a 0 and then with a 1. Each value is verified 
by reading it before a new value is written. 
The formal algorithm is as follows: 

For t = 0, 1, ...,n-l 
W t <— 0 
Ri ( = 0) 

Wi<- 1 
Ri ( = 1) 

The deterministic fault coverage of this 
test procedure is rather low. All that is 
known at the end is that there is at least one 
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Figure 2. Tiling a memory array for the checkerboard test: (a) pattern one; (b) 
pattern two. 


cell in the RAM that can be set to 0 and 1. 
This is because a fault in the decoder may 
cause the same cell to be referenced each 
time. Since the test performs four operations 
on each cell, its length is 4 N. 

Marching test. Perhaps the most widely 
used test algorithm in the industry is the 
marching test. A reason for its popularity is 
its simplicity, coupled with a moderate 
fault coverage. The marching-test algorithm 
initializes the memory array to all 0’s, and 
then scans the memory cells in ascending 
and descending orders. For each cell, 
scanning involves reading the cell for the 
expected value, writing the complement 
value, and reading it again. 

The idea behind this algorithm is that, 
while scanning the memory in ascending 
order, any direct coupling between the 
current cell and a higher address cell is 
detected when reading the latter. Along 
with this, any error in the higher address 
cell due to decoder faults will also be de¬ 
tected. Similarly, scanning the memory in 
the descending order detects all the effects 
on lower address cells. 

The formal algorithm is given below; 
the details can be found elsewhere. 1 

Step 1. W t <— 0 for i = 0, 1, .... n - 1 

Step 2.For i =0, 1,.... n - 1 

R< (= 0 ) 

Wi*- 1 

Rt ( = 1 ) 


Step 3.For i ~n - 1, n — 2,..., 0 
R;(=l) 

Wi<r- 0 

Ri( = 0 ) 

Step 4.Repeat steps 1 through 3, 
interchanging 0’s and l’s. 

The marching test detects all stuck-at 
faults and decoder faults. However, it does 
not detect all single coupling faults. Dif¬ 
ferent variations of the marching test, all of 
length O(A0, have been suggested in the 
literature. 1 

Checkerboard test. This simple algo¬ 
rithm, developed in an ad hoc manner, is 
designed for two-dimensional memory 
architectures. The algorithm fills the 
memory array with a checkerboard pattern 
by writing 0’s and l’s in alternate cells. 
Two patterns, as shown in Figures 2a and 
2b, are written. The cells are read after the 
application of each checkerboard pattern. 

Step 1. VFfij) <— 0 for i +j = even 
W (i j) <r- 1 for i +j = odd 

Step 2 .Ry t f) ( = 0) for i +j - even 
R(ij) ( = 1) for i+j = odd 

Step 3.Repeat steps 1 and 2, 

interchanging 0’s and l’s. 

The deterministic fault coverage of this 
test procedure is rather low. As with the 


Mscan test, a decocfer fault may cause only 
four cells at most to be referenced. There¬ 
fore, all that is known at the end of this 
procedure is that at least four cells in the 
RAM can be set to 0 and 1. 

Five-cell-neighborhood static-pattern- 
sensitive fault test. Many algorithms have 
been proposed to detect five-cell-neigh¬ 
borhood pattern-sensitive faults. All these 
algorithms are based on tiling the memory 
array. We briefly explain an algorithm re¬ 
ported by Kinoshita and Saluja, because 
this algorithm was later implemented as a 
built-in self-test. 3 Figures 3a and 3b show 
the tiling arrangements used by this algo¬ 
rithm for the static-pattern-sensitive fault 
test. The unmarked cells are the base cells. 
Each base cell is surrounded by four 
characters (A, B, C, D). The first phase of 
the test uses the tiling arrangement shown 
in Figure 3a. During this phase, the base 
cells are kept fixed at logic 0. The five-cell- 
neighborhood patterns are applied to the 
base cells using all four-tuples (16 patterns), 
consisting of variables A, B, C, and D. The 
base cells are read after the application of 
each pattern. The second phase uses the 
tiling arrangement of Figure 3b, and the 
above process is repeated. Then both phases 
are repeated with the base cells at logic 1. 

Row/column weight-sensitive fault test. 

Different test algorithms of varying test 
lengths have been proposed for testing 
RAMs for row/column weight-sensitive 
faults. 2 All the tests are of length 0(A 3/2 ) and 
use divide and conquer by recursive parti¬ 
tioning as the basic strategy. First the border 
cells of an array are tested. Then the two 
middle rows and columns are tested, thereby 
effectively partitioning the array into four, 
as Figure 4 shows. Partitioning continues 
recursively until all the cells of the array 
are tested. Testing the border cells involves 
scanning the memory array as in the 
marching test, and this helps to detect de¬ 
coder faults. The row/column weight- 
sensitive fault test also detects five-cell- 
neighborhood pattern-sensitive faults. 

Fault coverage. All the algorithms dis¬ 
cussed so far have been implemented as 
built-in self-tests. Some have also been 
implemented for embedded RAMs in ap¬ 
plication-specific integrated circuits. Table 
2 lists the complexities and fault-detection 
capabilities of the algorithms. Blank entries 
indicate that those classes of faults are 
either not detected or detected only to a 
small extent. The entries marked “unidi¬ 
rectional” mean that a cell may be sensitive 
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to one or more patterns or transitions, but 
all of them change the cell’s state from 
either 0 to 1 or 1 to 0. The table shows that 
the fault coverages offered by the Mscan 
test, marching test, and checkerboard test 
are rather poor. 


Test architectures 

Generally, test algorithms for RAMs are 
developed assuming no knowledge of the 
internal organization of the memory array. 
This makes sense, because a test algorithm 
should be generic to be applicable to 
memories with different internal organi¬ 
zations. Quite often, the internal details of 
a RAM chip are not released by the vendor 
and therefore are not available to custom¬ 
ers. The BIST logic designer, on the other 
hand, knows the internal organization and 
could use this knowledge to reduce the test 
time and area overhead with possible 
modifications to the test algorithm that do 
not sacrifice the fault coverage. For example, 
for reads and writes the BIST logic may be 
able to access multiple bits of an array in 
parallel if the technology and test algorithm 
allow, instead of accessing the bits serial¬ 
ly. Similarly, the internal organization might 
permit the testing of multiple arrays in 
parallel. The modifications made to test 
algorithms to suit memory’s internal struc¬ 
ture are analogous to the modifications 
made to high-level-language computer 
programs by optimizing and vectorizing 
compilers that take advantage of the com¬ 
puter’s internal organization. 

So far, BIST logic design has been driv¬ 
en in an ad hoc manner by the desire to 
implement specific test algorithms. That 



Figure 3. Tiling a memory array for the static-pattern-sensitive fault test: 
(a) phase one; (b) phase two. 
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Figure 4. Partitioning a memory array into four in the row/column weight-sensi¬ 
tive fault test: (a) memory array with the border cells tested; (b) memory array 
partitioned into four. 


Table 2. Summary of faults detected by the test algorithms. 


Test Procedure 

Order of 

Test Length 

Stuck-at-Faults 

Detected Faults 

Coupling Faults Restricted PSF 

Row/Column WSF 

Mscan Test 

0 (A!) 

Does not detect 
decoder faults 




Marching Test 

o (IV) 

All 

Does not detect all 
single coupling faults 



Checkerboard 

O(A0 

Does not detect 
decoder faults 




SPSF Tests 

O(N) 

All 


Unidirectional 


Row/Column Test 

0(iV 3/2 ) 

All 

Unidirectional 

Unidirectional 

Unidirectional 

PSF - pattern-sensitive 

: faults 

SPSF - static-patt 
WSF - weight-ser 

ern-sensitive fault 
isitive faults 
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Figure 5. Memory cell accesses for (a) single-array single-bit, (b) single-array multiple-bit, (c) multiple-array single-bit, 
and (d) multiple-array multiple-bit architectures. 


is, a new BIST logic design is carried out 
for each new algorithm implemented. Much 
design time goes into the implementation 
of features common to all test algorithms. 
This ad hoc approach also makes it diffi¬ 
cult to integrate a number of test algo¬ 
rithms on the same chip. An alternative 
(structured) approach is to develop generic 
test architectures for implementing a number 
of test algorithms. For example, in a mi¬ 
crocode-based test architecture, it might 
be possible to implement a class of different 
test algorithms by changing the microcode, 
just like changing the microarchitecture of 
a computer. * The test architecture proposed 
by Matsuda et al. seems to be a step in the 
right direction. 4 

Taxonomy. Although a number of RAMs 
have been implemented with BIST func¬ 
tions, to the best of our knowledge, no one 
has classified these implementations. Here 
we provide a taxonomy for classifying BIST 
RAM test architectures. The categories in 
a rigorous taxonomy must be exclusive to 
avoid ambiguity and exhaustive to avoid 
incompleteness, providing an unambigu¬ 
ous category for every instance presented 
to it. Our taxonomy matches the number of 
simultaneously tested arrays and the num¬ 
ber of simultaneously accessed bits within 
an array. Accordingly, we can classify all 
BIST RAM implementations into one of 
four test architectures: 

• single-array single-bit, 

• single-array multiple-bit, 


*This concept is similar to the idea of developing 
general-purpose computers (architectures) to do a va¬ 
riety of computations, as opposed to developing a 
special-purpose computer for each computation. 


• multiple-array single-bit, and 

• multiple-array multiple-bit. 

Single-array single-bit (SASB) test ar¬ 
chitectures are those in which a single 
array of the RAM chip is tested at a time 
and a single bit of the tested array is accessed 
at a time. Since a maximum of one bit from 
the entire memory chip is accessed at any 
instant, SASB architectures require the 
maximum amount of time for testing. Some 
classes of faults, such as arbitrary coupling 
faults, restrict the choice of test architec¬ 
ture to SASB architectures. Before the in¬ 
troduction of design for testability and BIST, 
external tester-based testing also limited 
the choice mostly to SASB architectures, 
because only one address can be transmit¬ 
ted from the tester to the chip at a time. 

Single-array multiple-bit (SAMB) ar¬ 
chitectures test a single array at a time, but 
within the tested array, multiple bits are 
accessed simultaneously. Generally, the 
accessed multiple bits are all from the same 
row; multiple cells from the same column 
are not accessed simultaneously, as this 
slows memory access. Multiple bits can be 
accessed by modifying the address decod¬ 
er. An SAMB test architecture in which all 
the n cells of a row (word) within an array 
are accessed simultaneously has often been 
referred to as line-mode testing. 

Multiple-array single-bit (MASB) test 
architectures can be used if a memory chip 
is organized as a number of independent 
arrays, allowing multiple arrays to be test¬ 
ed simultaneously. A single bit from each 
array is accessed at a time. The concept is 
similar to the simultaneous testing of many 
memory chips using external test equip¬ 
ment. In the MASB architecture, a maxi¬ 
mum of kl cells can be accessed at a time, 


where kl is the number of arrays in the 
memory chip. 

Multiple-array multiple-bit (MAMB) 
architectures use a combination of multi¬ 
ple-array and multiple-bit testing. A number 
of arrays are tested simultaneously, with a 
number of cells (normally within a row) in 
each array accessed simultaneously. 
Therefore, as many as kin cells can be ac¬ 
cessed simultaneously. Sridhar’s parallel 
simultaneous testing of a number of bits 
from all the arrays is an example. 5 

Figure 5 illustrates these concepts with a 
RAM organized as four arrays. The above 
discussion demonstrates that the SAMB, 
MASB, and MAMB architectures provide 
a speedup over the SASB architecture. An 
SAMB architecture can, at best, reduce the 
test length by a factor of n, if all the n cells 
in a row within an array are accessed si¬ 
multaneously. The effective speedup can 
be less than n for certain classes of test 
algorithms because, during some stages of 
testing, these algorithms require the con¬ 
tents of part of the row to be kept unchanged 
when the rest of the row is being tested. 
Examples are the ping-pong test for cou¬ 
pling faults 6 and the row/column weight- 
sensitive fault test. 2 The MASB and MAMB 
architectures can give a maximum speedup 
of kl and kin, respectively. 

Some algorithms are inherently serial 
and therefore do not attain the maximum 
speedup offered by the test architecture. 
Given a test algorithm, the BIST designer 
must choose one of the four architectures, 
considering test time, speedup, and tech¬ 
nology. Alternatively, given a memory chip 
design, the BIST designer can select a test 
architecture based on the available tech¬ 
nology and silicon area and then select test 
algorithms that can be implemented on the 
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Figure 6. A generic block diagram of random-logic-based BIST logic for RAMs 
(based on Ohsawa et al. 7 ). 


selected architecture. Such an approach 
uses more efficiently the silicon area set 
aside by the memory designers for the test 
logic. Only algorithms with good fault 
coverage should be selected. 

All the test implementations reported so 
far can be categorized into one of the above 
four test architectures. Memory sizes have 
now reached the stage where an SASB 
architecture is almost impractical. Gener¬ 
ally, as the memory size increases, the 
number of arrays increases, with the size of 
an array remaining more or less constant. 
Therefore, in the future we can expect 
many more designers to use the MASB and 
MAMB test architectures. 

Modifying test algorithms. If the ar¬ 
rays are independent of each other and 
cells of different arrays do not interact, an 
algorithm developed for an SASB archi¬ 
tecture need not be modified for a MASB 
architecture. However, modifications may 
be required to implement a conventional 
SASB algorithm in an SAMB or MAMB 
architecture. 

Most test algorithms can be modified to 
benefit from the simultaneous access of 
multiple bits of a row. When multiple bits 
of an array are accessed simultaneously, 
faults due to interactions between the si¬ 
multaneously accessed cells may not be 
detected, unless special care is taken. Sridhar 
describes a method to detect errors caused 
by interactions between cells accessed si¬ 
multaneously. 5 

BIST logic 

Memory chip designers generally use 
aggressive design rules to maximize the 
number of cells in a chip and to minimize 
the memory access time. This imposes rather 
hard constraints on the BIST logic design¬ 
er. In general, the BIST logic designer tries 
to minimize 

• the area occupied by the BIST hard¬ 
ware, 

• the performance penalty incurred for 
the normal memory operation, 

• the number of additional pins required, 

• the disparity between the functional 
speed and testing speed, and 

• the test time, by using the memory’s 
internal structure. 

Conceptually, the BIST logic can be 
divided into four parts: control logic, ad¬ 
dress-generation logic, data-generation and 
response-verification logic, and test-trig¬ 
ger logic. Figure 6 (based on Ohsawa et 


al. 7 ) shows a generic BIST organization 
for testing RAMs. We have modified the 
figure to show the main parts of the BIST 
logic clearly. 

Control logic. The control logic initiates 
and stops testing and supervises the control 
flow of the test algorithm. It can be imple¬ 
mented using random logic or microcode. 
Random logic offers higher speed and has 
traditionally been used for designing the 
control logic; nevertheless, recent designs 
seem to prefer microcode-based control. 
For large memories (4 megabits and more), 
microcode-based BIST design has been 
shown to have an area overhead which 
does not exceed that of random-logic-based 
designs. 3 Therefore, the flexibility and 
implementational ease offered by micro¬ 
code makes it superior to random logic for 
large RAMs. 

Microcode fits well with RAM technol¬ 
ogy because of its regular structure. For 
BIST RAMs, it may be even more area 
efficient than random logic, because the 
aggressive design rules used for RAM cells 


can also be used for the microcode array. 
Furthermore, the designer can use such 
microcode-optimization techniques as 
microprocedures, microstacks, and encod¬ 
ing by grouping of microinstruction fields, 
developed for microcode-based comput- 


Address-generation logic. Almost all 
test algorithms require the addresses to be 
generated in a fairly uniform manner. The 
control logic can be designed to generate 
the addresses, but leaving this task to a 
separate unit is better. For most algorithms, 
address generation can be achieved by lin¬ 
ear-feedback shift registers, registers, or 
counters, with occasional intervention from 
the control logic. With the MASB and 
MAMB architectures, a single address- 
generation unit can be used for testing 
multiple arrays. 

Data-generation and response-verifi¬ 
cation logic. The data-generation unit 
produces the test pattern(s) to be written in 
the cells. Given a test architecture, differ- 
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ent strategies can be used for data genera¬ 
tion as well as response verification. Lin¬ 
ear-feedback shift registers or counters as¬ 
sisted by the control logic can generate 
data. In an SASB architecture, the correct¬ 
ness of the read values can be verified 
either by comparing them against the ex¬ 


BIST implementations 

Below we examine several academic 
and commercial BIST implementations. 
Our purpose is not a definitive compari¬ 
son; rather, it is to discuss important im¬ 
plementation features such as test algo¬ 
rithms, test architectures, and control 
logic. We have tried to include most of the 
BIST implementations reported in the lit¬ 
erature and to present them more or less 
in chronological order. The terminology is 
that used by the authors. 

On-chip compact test scheme. Salu- 
ja, Sng, and Kinoshita proposed a BIST 
design for testing RAMs for five-cell- 
neighborhood pattern-sensitive faults. 1 
They grouped the patterns required to test 
a cell for such faults into different classes, 
depending on the “weight” of the patterns. 
Then they developed procedures to apply 
these patterns using optimal test length 
sequences. The grouping of the patterns 
helped to keep the test generators and re¬ 
sponse verifiers simple for BIST imple¬ 
mentation, without causing information 
loss due to data compaction at the re¬ 
sponse-verification end. 

For the control logic, they proposed 
both random-logic-based and microcode- 
based designs. They also proposed a 
simple and effective instruction set for the 
microcode-based implementation. The on- 
chip compact test scheme was proposed 
and studied in an SASB architecture, al¬ 
though the feasibility of using it in a 
MASB environment was considered. Esti¬ 
mated area overhead for a 64-kilobit static 
RAM is 1.21 percent; for a 1-megabit stat¬ 
ic RAM, 0.09 percent. 

Parallel test using signature analyz¬ 
er. Sridhar proposed a scheme that uses 
a parallel signature analyzer to access bit 
lines from different arrays simultaneous¬ 
ly. 2 The parallel signature analyzer oper¬ 
ates in three modes: the scan mode, the 
write mode, and the signature/read mode. 
In the scan mode, the analyzer is loaded 
with a specific pattern from outside the 
chip by serially scanning in the bits. This 
mode is also used for scanning out the 
contents of the analyzer (the signature) at 


pected values or by signature analysis. 
Direct comparison is superior, because it 
can locate single stuck-at faults. Further¬ 
more, with signature analysis, some faults 
may go undetected because of aliasing er¬ 
rors. For the SAMB, MASB, and MAMB 
architectures, other fault-detection meth¬ 


the end of the test. In the write mode, the 
value stored in the analyzer is written to a 
number of bit lines in parallel. Finally, in 
the signature mode, the contents of the 
memory cells written earlier are read, and 
a new k-bit signature is generated. This 
signature determines whether an error 
has occurred. 

This is not a fully BIST scheme, be¬ 
cause it requires the scanning in of data 
from outside the chip. The scheme uses 
the marching-test algorithm, modified to 
suit parallel testing. It can be categorized 
as a MAMB approach, as the parallel sig¬ 
nature analyzer can access multiple bits 
from multiple arrays simultaneously. The 
MAMB architecture results in very fast 
testing. 

A potential problem with the scheme is 
that it requires an external tester to scan 
in the data. Another problem is the low 
fault coverage offered by the marching 
test. If a wide enough parallel signature 
analyzer is used, then the probability for 
aliasing errors will be very low. The error- 
detection capability can be significantly 
enhanced by monitoring the quotient bit of 
the analyzer, in addition to verifying the 
final signature. Estimated area overhead 
for a 256-kilobit dynamic RAM is 1.0 to 
2.2 percent; for a 64-kilobit static RAM, 

1.8 to 2.9 percent. 

Self-testing dynamic RAM. You and 

Hayes proposed another type of parallel 
testing: reconfiguring the cells of an array 
into a circular shift register and using a 
built-in test generator to test multiple bits 
concurrently. 3 The dynamic RAM is orga¬ 
nized as two identical arrays, and the ar¬ 
rays are tested in parallel to reduce the 
overall testing time. The test patterns are 
generated by reconfiguring the cells of 
each array to act as a circular shift regis¬ 
ter during testing. When a row (that is, a 
word line) within an array is activated, the 
contents of the n cells of the row are 
transferred to n bit lines, sensed by n 
sense amplifiers, and then written to the 
adjacent cells in the same row. Each n- 
cell row thus acts as an r?-bit shift register. 
The data shifted out from the right-most 
sense amplifier is saved in a flip-flop and 
is stored in the left-most cell of the next 
row in the next shift cycle. 


ods — in addition to comparison against 
expected values — are comparison of val¬ 
ues read from multiple bits, AND reading, 
and OR reading. 

In the MASB and MAMB architectures 
another convenient verification method is 
comparing the outputs of symmetrically 


Thus, all m rows of an array effectively 
form an mn-bit shift register. By saving 
the initial contents of the right-most cell of 
the last row, the array realizes an mn-bit 
circular shift register. The standard sense 
amplifier circuits are modified so that 
when a bit value is read from one cell, it 
can be written into the adjacent cell in the 
same row. This is accomplished by intro¬ 
ducing pass transistors between the phys¬ 
ically adjacent bit lines and may adversely 
affect the sensitivities of the sense ampli¬ 
fiers and the RAM access time in the nor¬ 
mal operation mode. 

An on-chip comparison circuit consist¬ 
ing of exclusive-OR gates detects faults 
by comparing the outputs of symmetrically 
placed cells of the two arrays. The self¬ 
testing dynamic RAM implementation can 
be categorized as a MAMB test architec¬ 
ture, since two arrays are tested in paral¬ 
lel and multiple bits of an array (all the 
bits of a row) are accessed simultaneous¬ 
ly. This scheme detects bit-line imbalance 
faults and restricted types of pattern-sen¬ 
sitive faults in which a write operation be¬ 
comes faulty in the presence of a few 
specific patterns in the cell’s adjacent 
cells. It does not detect faults caused by 
transitions in the neighborhood. The area 
overhead for a 4-kilobit dynamic RAM is 
about 12 percent, and the estimated over¬ 
head for a 1-megabit dynamic RAM is 
about 5 percent. 

Parallel testing for VLSI memories. 

Inoue et al. proposed the line-mode test, 
a special case of SAMB testing. 4 In the 
line-mode test, all cells connected to a 
word line are tested simultaneously. The 
on-chip test circuit can perform parallel 
write and parallel compare. The parallel 
write circuit writes data into all cells con¬ 
nected to a word line, and the parallel 
compare circuit compares the data in par¬ 
allel with the expected data. Apart from 
the memory cell arrays, separate tests 
check the decoders, the test logic, and 
the I/O circuits. The memory cells are 
tested with the marching-test algorithm. 

The test circuit occupies less than 1 
percent of the chip area for a 2-megabit 
dynamic RAM. The parallel write opera¬ 
tion allows only certain patterns to be ap¬ 
plied to the cells; therefore, the technique 
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placed bits in the tested arrays. An advan¬ 
tage of the parallel comparison methods is 
that the expected values need not be gener¬ 
ated. A basic assumption is that all bits 
would not simultaneously have erroneous 
values. In large dynamic RAMs, memory 
cell pitches are very small. Thus, the addi¬ 


tional area of parallel write and parallel 
compare circuits should be small enough 
to be arranged in the small pitch. 

Test trigger logic. All BIST RAMs have 
a normal mode in which the BIST logic is 


inactive and one or more test modes in 
which the BIST logic is active. The test 
modes can be entered using overvoltages, 
extra package pins, or unique timing se¬ 
quences with such inputs as Chip Enable, 
Write Enable, Row Address Strobe, and 



Block diagram of microcode-based BIST logic for the row/column weight- 
sensitive fault test. 


Parallel testing for pattern-sensitive 
faults. Mazumder and Patel proposed a 
BIST parallel testing scheme in which a 
number of cells on the same word line are 
accessed simultaneously. 5 The decoder is 
modified so that in the test mode multiple 
bit lines are selected, allowing the same 
data to be simultaneously written to multi¬ 
ple cells of the same word line. In the 
read mode, a multibit comparator concur¬ 
rently compares the outputs of the bit 
lines. The additional hardware is designed 
to fit within the intercell pitch. The algo¬ 
rithm detects both static- and dynamic- 
pattern-sensitive faults over the nine-cell 
neighborhood of every cell. Mazumder 
and Patel estimate the area overhead for 
a 256-kilobit RAM to be about 0.4 per¬ 
cent. 

Built-in processor for self-test. Ritter 
and Muller have reported a BIST scheme 
in which a built-in processor tests and re¬ 
pairs large RAMs. 6 Repair requires fault 
localization and computation of a repair 
plan, calling for an intelligent self-test 
concept. This and the demand for high 
flexibility necessitated a test processor. 
The test processor also allows for easier 
and faster adaptation to various types of 
memory technology and organization. 
Furthermore, complex algorithms can be 
incorporated later, when new memory 
technologies are developed or new types 
of faults and fault models (not yet consid¬ 
ered) are introduced during product life. 
The test function can be applied not only 
at manufacturing time, but also during in¬ 
coming inspection and system-mainte¬ 
nance service. The main components of 
the test processor are RAM cells, ROM 
cells, and decoders. The size of the ROM 
holding the test program is 512 x 14 bits. 
The area overhead for a 1-megabit RAM 
is about 5 percent, and the test architec¬ 
ture can be classified as an SAMB archi¬ 
tecture. 

CMOS dynamic RAM with BIST func¬ 
tion. Perhaps the first fully BIST imple¬ 
mentation in the industry was the one re¬ 
ported by Ohsawa et al. for a 4-megabit 


RAM. 7 Their scheme implements a check¬ 
erboard test pattern and its complement, 
and their test architecture falls under the 
MAMB category. The RAM is divided into 
eight arrays, two of which are activated in 
a read/write cycle. From each of the test¬ 
ed arrays, eight bits are accessed simul¬ 
taneously. A data comparator compares 
the read pattern with the expected pat¬ 
tern. The control logic is implemented by 
random logic. The BIST mode is entered 
through a unique timing sequence. Figure 
6 in the main text shows a block diagram 
of this scheme. The area overhead for the 
BIST logic is less than 1 percent. A poten¬ 
tial problem is the low fault coverage of 
the checkerboard test. 


Row/column pattern-sensitive fault 
test implementation. The row/column 
weight-sensitive fault test algorithm has 
been implemented using both random- 
logic-based and microcode-based de¬ 
signs. 8 Both schemes use the SASB ar¬ 
chitecture. We shall briefly describe the 
microcode-based implementation to pro¬ 
vide more insight into the workings of mi¬ 
crocode-based BIST. The figure above 
shows a simplified block diagram of the 
microcode-based implementation. The 
main control flow is implemented using 
microcode, and such support functions as 
the address-generation logic are imple¬ 
mented using registers and combinational 
logic. Central to the BIST logic is the 15 x 
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Column Address Strobe. Using unique 
timing sequences is better than using over¬ 
voltages and extra package pins, because 
the latter methods may be incompatible 
with existing systems. Also, the overvolt¬ 
age method requires either an additional 
power supply or the generation of an addi¬ 


tional voltage signal. Voss et al. describe 
an implementation of a 256-kilobit x 1-bit 
static RAM with multiple test modes in 
which the test modes are entered by a 
unique timing sequence. 8 They also de¬ 
scribe how a particular test mode can be 
selected using the normal address input 


pins, if there are multiple test modes. Miyaji 
et al. describe the design and implementa¬ 
tion of a test trigger circuit for megabit 
static RAMs that uses the Chip Enable and 
Write Enable signals to generate a unique 
timing sequence for entering the test mode. 9 


10-bit control store, which controls the ini¬ 
tialization, sequencing, and completion of 
testing. The control store is conceptually 
divided into four microroutines. Control 
passes from one microroutine to another 
when the former issues a call signal to the 
latter; control passes back to the former 
when the latter issues a return signal. A 
microstack stores the return addresses in 
the proper order during nested calls. A 4- 
bit microprogram counter points to the mi¬ 
croinstruction currently being executed. 

The address-generation logic consists 
of a register file and some combinational 


logic (glue logic). The registers hold the 
row and column addresses of the cell be¬ 
ing tested and the cell being read or writ¬ 
ten. The width of the registers depends on 
the memory organization and the size of 
the cell array. The microcode initializes 
and updates the register file. 

A major innovation of this scheme is the 
implementation of a moderately complex 
algorithm with a small control store, using 
microcode-optimizing techniques such as 
microprocedures and microstacks. The 
row/column weight-sensitive fault test has 
higher fault coverage than the other algo¬ 


rithms (see table below). A potential prob¬ 
lem with the SASB implementation is that 
the test time is comparatively long. How¬ 
ever, the test time can be reduced by us¬ 
ing the MASB or MAMB test architectures. 
The area overhead of the random logic 
design for a 4-megabit RAM is less than 
0.8 percent. 

Serial interfacing for embedded- 
memory testing. Nadeau-Dostie, Silburt, 
and Agarwal proposed a serial interfacing 
scheme for testing embedded RAMs. 9 
Embedded RAMs are on-chip RAMs 


Summary of different implementations. (Fault coverage for each implementation can be inferred from Table 2 in the main 
text, which shows the coverage for each type of algorithm.) 


Implementation 

Algorithm 

Test Architecture 

Control Logic 

Type of RAM 

On-chip compact test scheme 

SPSF test 

SASB 

Random logic 
microcode 

SRAM 

Parallel test using signature analyzer 

Marching test 

MAMB 

Random logic 

SRAM,DRAM 

Self-testing DRAM 

Restricted PSF test 

MAMB 

Random logic 

DRAM 

Parallel test for VLSI memories 

Marching test 

SAMB 

Random logic 

DRAM 

Parallel test for PSFs 

PSF test 

SAMB 

Random logic 

DRAM 

Built-in processor for self-test 

Not specified 

SAMB 

Processor 


CMOS DRAM with BIST 

Checkerboard test 

MAMB 

Random logic 

DRAM 

Row/column test implementation 

Row/column test 

SASB 

Random logic 
microcode 

SRAM 

Embedded-memory testing 

Marching test 

Galpat 

Walk 

MAMB 

Random logic 

SRAM 

16-Mbit CMOS DRAM 

Marching test 

Mscan test 

SAMB 

Microcode 

DRAM 


MAMB - multiple-array multiple-bit 
SAMB - single-array multiple-bit 
SASB - single-array single-bit 
SPSF - static-pattern-sensitive fault 
PSF - pattern-sensitive fault 
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Future trends 

BIST technology combines several dif¬ 
ferent areas: fault models, test algorithms, 
test implementation, and fault diagnosis. 
Changes can be expected in each of these 
areas as technology progresses. Below, we 


whose address, data, and read/write 
controls cannot be directly controlled or 
observed through the chip’s I/O pins, 
making them good targets for BIST ap¬ 
plications. The implemented scheme in¬ 
volves shifting data from one memory 
cell to another, similar to the self-testing 
dynamic RAM method described earlier. 
Although both schemes use the MAMB 
architecture, there are some differences. 
While the self-testing dynamic RAM 
scheme shifted data only within an array 
and independently tested two arrays in 
parallel, the new scheme shifts data 
within an array as well as across arrays, 
by shifting the data at the end of one ar¬ 
ray to the beginning of next array in a 
daisy-chained fashion. This makes shar¬ 
ing the BIST logic among multiple arrays 
easier, because fewer interconnection 
lines need to be routed between the 
BIST logic and the RAM blocks. Further¬ 
more, in the serial interfacing scheme, 
multiplexers implement the shifting 
along the I/O data path. Therefore, no 
modification is required in the RAM. The 
implemented algorithms are adaptations 
of the marching test, Galpat (galloping 
patterns), and walk algorithms. 

16-Mbit CMOS DRAM with BIST 
function. Using microcode-based con¬ 
trol logic, Takeshima et al. have imple¬ 
mented the marching test and a scan 
read/write test with a checkerboard pat¬ 
tern for a 16-megabit dynamic RAM. 10 
The size of the control store is 18 x 10 
bits. Perhaps theirs is the first industrial 
BIST RAM implementation using micro¬ 
code. The dynamic RAM enters the test 
mode through a unique timing se¬ 
quence. 
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repaired (if necessary) by bringing in the 
spare rows and columns. With such new 
fault-tolerance techniques as dynamic re¬ 
configuration, fault models based on logi¬ 
cal adjacency become irrelevant, whereas 
those based on physical adjacency and 
electrical connectivity become more rele¬ 
vant. Future fault models must consider 
the effects of such reconfiguration within 
memory chips. With the new high-speed 
RAM realizations, such as gallium arsenide 
RAMs, future models must also consider 
delay faults. 

Test algorithms. When a memory chip 
is reconfigured, physically adjacent cells 
may no longer have consecutive addresses. 
Test algorithms for the detection of physi¬ 
cal neighborhood pattern-sensitive faults 
have to account for this fact. Furthermore, 
we believe that there will be a trend to find 
optimal or near-optimal, yet simple, test 
algorithms. These will save testing time as 
memory size continues to grow, and BIST 
logic will be used for maintenance testing 
of RAMs embedded in a system. 

Test implementation. When a memory 
chip is being used in a system (that is, when 
the chip contains valid data), it cannot be 
tested on line because the test procedure 
might destroy the memory contents. Fu¬ 
ture systems may implement BIST algo¬ 
rithms that have on-line test capabilities. 
Further research is required not only to 
develop such algorithms, but also to deter¬ 
mine the merits and demerits of such an 
approach, especially since most memory 
systems use error-correction code at some 
level. 

Fault diagnosis and self-reconfigura¬ 
tion. In general, current BIST implemen¬ 
tations cannot diagnose faults. In the fu¬ 
ture, BIST will potentially be used in field 
diagnosis. Such diagnosis will help in re¬ 
configuration of memory chips and repair 
of multichip memory modules (silicon mass 
storages). 


T he separation of test algorithm and 
test architecture clearly shows the 
range of possible implementations 
for a given test algorithm. The test archi¬ 
tecture-based approach is more versatile 
than the ad hoc design approach for BIST 
logic design, especially with various de¬ 
sign constraints. It also facilitates the inte¬ 
gration of a number of test algorithms within 
the same chip. 

Our taxonomy for classifying BIST ar- 
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chitectures provides a framework to de¬ 
scribe widely differing implementations at 
a level of abstraction that eliminates many 
algorithm-related details, while preserv¬ 
ing the important implementation charac¬ 
teristics. We expect that most future imple¬ 
mentations in large RAMS will use the 
test-architecture-based approach, since 
it can easily adapt to changes in tech¬ 
nology. ■ 
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Chain Reactions 
in Networks 


Udi Manber 
University of Arizona 


C omputer programs are not always 
correct and computer hardware is 
not always fault-free. A hardware 
failure can easily bring down a computer, 
and software errors can sometimes do that 
too. Most computer users are accustomed 
to periodic shutdowns; except for applica¬ 
tions requiring a high level of reliability, 
infrequent shutdowns, though undesirable, 
are acceptable. Now, however, since most 
computers are connected by a myriad of 
communication networks, there is the 
danger that a design failure either in one 
computer or in one network protocol will 
propagate throughout a network, causing a 
breakdown of the entire network. This is 
clearly unacceptable. 

We use the notion of chain reactions to 
characterize these breakdowns. A chain 
reaction is defined by Webster’s New World 
Dictionary as a “self-sustaining series of 
chemical or nuclear reactions in which 
reaction products keep the process going.” 
Except for restricting the reactions to 
chemical or nuclear reactions, this defini¬ 
tion fits our subject perfectly. 

The increase in network availability has 
brought numerous network applications that 
require complicated protocols and distrib¬ 
uted algorithms. This added complexity 
substantially raises the potential for design 
failures. The main purpose of this article is 
to highlight some failures and discuss their 
prevention. Unfortunately, there are no easy 
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Theoretically, it’s 
impossible to prevent 
the berserk loops of 
messages that can bring 
down an entire 
computer network. But 
a carefully applied set 
of rules will minimize 
these disasters. 


ways to safeguard software systems. But 
the more we understand the weaknesses, 
the better equipped we will be to protect 
against them. 

This article identifies a set of situations 
that are susceptible to network disasters. It 
presents several examples of actual break¬ 
downs, which, although they occurred in 
different types of networks, have great 
similarities. It also gives several examples 
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of potential breakdowns that can result 
from very subtle design failures. A general 
program that can prevent or even detect all 
potential chain reactions in an arbitrary 
protocol is impossible to design (see The¬ 
orem 1), but this article does suggest sev¬ 
eral steps to minimize the problem. Much 
of this discussion is part of the “folklore” 
among protocol designers. My purpose here 
is to unify some ad hoc observations and 
solutions. It is widely believed that dis¬ 
tributed programs in general can have very 
subtle design failures that are hard to detect. 
This article supports that belief, but it also 
helps in understanding and preventing 
errors. This is especially important since 
network protocols are becoming more 
and more diverse, interleaved, and 
complicated. 

A chain reaction in an 
Ethernet 

The first example involves a local area 
network. The problem was caused by an 
error in a network protocol of a new oper¬ 
ating system, Berkeley Unix 4.3. The error 
occurred when the operating system was 
installed on workstations (Microvaxs) 
connected by an Ethernet that also connected 
workstations still running the previous 
version (4.2). In describing details of the 
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Ethernet 


Figure 1. The network protocols in¬ 
volved in the Ethernet problem 
(IP=Internet Protocol; ARP = Address 
Resolution Protocol). 


protocols used, the discussion is limited to 
the way the protocols were used in that 
particular case and to the parts relevant to 
the breakdown. 

Background. An Ethernet is a broad¬ 
cast medium in which all messages reach 
all destinations. Each host has an Ethernet 
controller, which is responsible for deter¬ 
mining which messages are addressed to 
its host and thus should be picked from the 
network and forwarded to the host. The 
messages picked by the controller are ei¬ 
ther messages addressed to the host or 
broadcast messages. The protocol to which 
the controllers delivered the messages they 
picked was the Internet Protocol (IP), which 
serves as the internetwork layer in the In¬ 
ternet. IP is a complicated protocol, re¬ 
sponsible for many tasks. In particular, IP 
was connected to another protocol, the 
Address Resolution Protocol (ARP), which 
is used to translate between high-level In¬ 
ternet addresses and low-level physical 
addresses. Each message had two address¬ 
es: an IP address and an Ethernet address. 
ARP was used as an interface between the 
two. Both IP and ARP are general-purpose 
protocols designed for large networks, but 
they can also be used (and often are) inside 
only one local area network. 

Figure 1 illustrates the connections among 
the Ethernet controller, IP, and ARP. A 
correct message sent on the Ethernet has 


the right Ethernet address and the right IP 
address. It is picked by the appropriate 
controller using the Ethernet address and 
forwarded to IP. IP checks the IP address 
and then handles the message (for example, 
it assembles packages) and delivers it to 
the host through other protocol layers. IP 
also receives messages from the host and 
uses ARP to find the correct Ethernet ad¬ 
dress for them. 

The breakdown. The chain reaction 
arose from an inconsistency between the 
conventions for specifying broadcast mes¬ 
sages in the new operating system and the 
one it replaced. In Berkeley Unix 4.2 a 
broadcast is denoted by all 0’s in the IP 
host field; in 4.3 it is denoted by all 1’ s. The 
network in question had both 4.2 and 4.3 
machines. Consider the fate of a 4.3 
broadcast message, which had a 4.3 IP 
broadcast address with all l’s in the host 
field. This message was picked up by the 
4.2 Ethernet controllers (because its Eth¬ 
ernet broadcast address was correct), and 
forwarded to the 4.2 IP. The 4.2 IP did not 
recognize the IP address with all 1 ’s. 

Being a good citizen, IP tried to resolve 
the apparent error. Fortunately, IP had a 
mechanism for doing just that: It asked 
ARP to find the correct Ethernet address 
for this IP address so that the message 
could be forwarded to its intended desti¬ 
nation. ARP, however, had no information 
about that particular address, so it created 
a request message to all the other ARPs, 
saying in essence, “Does anyone know 
how to translate this address?” Since no 
ARP could help, these messages were dis¬ 
carded. 

So far the results of this error were not 
disastrous. Some broadcast messages were 
not delivered, and they caused several er¬ 
ror messages and some unnecessary load 
on the protocols. The effects of the error 
were compounded, however, by the pres¬ 
ence of programs that generated broadcast 
messages frequently (such as rwho). Net¬ 
works with both 4.2 and 4.3 machines did 
slow down (sometimes significantly), but 
they didn’t crash. It is the following attempt 
to correct the problem that makes this ex¬ 
ample more interesting. 

It was clear to the people monitoring the 
message traffic that the problem was caused 
by messages to a certain IP address (with 
all l’s), which for some unknown reason 
generated numerous ARP requests. At a 
certain site the following quite natural so¬ 
lution was attempted: If ARPs cannot fig¬ 
ure out that the message is a broadcast 
message, let’s tell them. So an entry was 


made (by hand) in one ARP’s table, trans¬ 
lating that IP address to the Ethernet 
broadcast address. The idea was that ARP 
requests would reach this one ARP that 
could resolve them, and the original mes¬ 
sages would be made into the broadcast 
messages they were supposed to be. 

The result was quite different. Consider 
one 4.2 IP that does not recognize the 4.3 IP 
message as a broadcast message and asks 
its ARP to help. ARP finds out that the 
message is indeed a broadcast message, so 
IP forwards the message with an Ethernet 
broadcast address. But this forwarded 
message still causes the same problem. 
The 4.2 IPs do not recognize its IP address, 
which remains the same; they use their 
ARP to resolve the address; the ARPs re¬ 
solve the address; and more broadcast 
messages are generated. If there are k 4.2 
machines, then each original broadcast 
message will be regenerated k times, each 
of those k broadcast messages will be re¬ 
generated k times, and so on. 

The result was that the network was 
swamped with these broadcast messages, 
and several machines crashed very quick¬ 
ly. Not only that, but the only way to 
correct the problem was to physically dis¬ 
connect the machines and restart everything 
(without the extra entry in the ARP table, 
of course). 

Infinite loops of mail 
messages 

Background. When a user moves from 
one place to another, or even from one 
computer to another at the same site, the 
mail should be forwarded appropriately. 
This can be done by using forwarding 
commands; for example, in Unix one can 
specify the forwarding address in a file 
named .forward. Before the mail is deliv¬ 
ered, the .forward file is consulted and, if it 
is not empty, the mail is automatically 
forwarded to the address in the file. Suppose 
that a careless user forms a cycle of for¬ 
warding pointers; for example, machine A 
has a .forward file pointed to machine B 
and machine B has a .forward file pointed 
to machine A. (Unfortunately, this is not 
unusual; a user may decide to receive the 
mail at site B, and the easiest way to do so 
is by adding a .forward file at site A to point 
to B. That user may not be aware that site 
B already has a .forward to site A.) 

Let’s call a user whose mail path contains 
a cycle a cycled user. If no action is taken, 
a mail message sent to a cycled user will 
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bounce from one site to another in an infinite 
loop. In practice, mail messages are aged. 
The number of hops that a message can 
take has a limit (for example, 30). When 
the limit is reached, the attempt to deliver 
the message is ended, and an error message 
is generated. (See a later section for more 
detail on aging messages.) 

The breakdown. Although forwarding 
cycles are not uncommon, they do not 
cause any problems except for the cycled 
user, who, of course, cannot get any mail. 
Consider, however, the following scenar¬ 
io, which actually happened. John, who 
was (unknowingly) a cycled user, noticed 
that mail was not coming through. His 
knee-jerk reaction was to send a test mail 
message to himself to see what would 
happen. Well, let’s see what happened: 
The mail bounced in the cycle until the 
limit was reached; then, an error message 
was generated. An error message is ad¬ 
dressed to the sender, who, in this case, 
was also the intended recipient. Of course, 
the same fate awaited the error message; it 
bounced in the cycle until the limit was 
reached, and another error message was 
generated, and so on. And, as if that was 
not bad enough, the messages were in fact 
getting longer. An error message contains 
a header that identifies it as an error mes¬ 
sage and identifies its cause, and it also 
contains the original message. The growth 
was linear and not exponential, but it was 
sufficient to crash the system. 

The two machines involved in the cycle 
were connected by a fast local area network. 
The messages bounced back and forth 
rapidly and grew rapidly, until they filled 
the available buffers and crashed the ma¬ 
chines. If the two machines had been con¬ 
nected by a slow network, the loop would 
have consisted of messages going back and 
forth every few minutes (or hours). Such a 
loop would have degraded the performance 
of the network slowly but could have re¬ 
mained undetected for a long time. 

Another variation of an infinite message 
loop happened at the University of Arizona 
in May 1989. As a result of an erroneous 
setup of an initialization file (the details 
are immaterial to this discussion), a work¬ 
station named Corona, which was connected 
to a file server named Baskerville, “thought” 
that it was Baskerville itself. When Corona 
was rebooted, it tried to establish connec¬ 
tion with, among others, Baskerville. The 
connection was unsuccessful because 
Baskerville, being smart, did not want to 
talk to itself (the message Baskerville re¬ 
ceived from Corona was something of the 


Figure 2. An infinite loop of messages. 


form “Hi, I’m Baskerville.”). An error 
message was generated about the failed 
connection. The error message was ad¬ 
dressed automatically to a mailing list 
(maintained on a computer called Megaron) 
that included the staff responsible for the 
mail. Unfortunately, Corona was also the 
personal machine of a staff member who 
received her mail there and who was on the 
mailing list. The error message thus could 
not be delivered, and again an error mes¬ 
sage was generated, addressed to — you 
guessed it — the staff. 

Figure 2 shows this chain of events. 
Notice that, because several people were 
involved, the resulting loop was more seri¬ 
ous than the one previously described. Each 
error message was sent to the whole mail¬ 
ing list. The result was a crash of several 
machines—the ones on which the staff 


members received their mail—because their 
disks got full. Again, the error messages 
got bigger and bigger, thus speeding the 
process. 

An even more serious loop might have 
been formed if two staff members had their 
mail delivered to Corona or if another 
machine belonging to a staff member had 
been rebooted at the same time (the setup 
error was identical in most machines). In 
those cases every error message would 
have been sent to both members, which 
would have generated two error messages, 
and so on. This example illustrates the 
danger of multiple forwarding or any use 
of large mailing lists, especially ones that 
are supposed to receive error messages. It 
is more prudent to deposit the errors in a 
file and have whoever is responsible look 
at that file occasionally, rather than to use 
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the normal mail program. Huge mailing 
lists with users all over the world are quite 
common today. Failures involving such 
mailing lists can be disastrous. 

Additional examples 

Four more examples of real or potential 
chain reactions further illustrate how frag¬ 
ile network protocols can be. 

The most famous example of a chain 
reaction occurred in the Arpanet in 1980. A 
hardware failure that caused bit dropping 
in one host caused a loop of routing update 
messages that brought down the whole 
network. This breakdown is discussed in 
detail by Rosen. 1 

From our earlier discussion of local area 
networks, recall that a message is always 
broadcast but that only the intended desti¬ 
nation actually reads the message (if ev¬ 
erything works properly). Now suppose 
that we want to connect several local area 
networks, using bridges, into one network, 
something that is becoming very common. 
Suppose that we want to keep the idea of 
broadcasting messages throughout the 
combined network. If the combined net¬ 
work does not contain any cycle, a flood¬ 
ing algorithm works very well. That is, 
every bridge that connects several networks 
forwards messages to all the networks con¬ 
nected to it except the one from which the 
message came. If, on the other hand, the 
interconnection contains cycles, then we 
can use a spanning tree (a connected sub¬ 
graph containing all the nodes but no cy¬ 
cles) for the broadcasting (see Figure 3). 

Perlman gives a protocol for finding a 
spanning tree in such an environment. 2 
Perlman and Varghese present an example 
of a seemingly straightforward improve¬ 
ment to Perlman’s protocol and show that 
this “improved” protocol can cause an ex¬ 
ponential number of messages. 3 We can¬ 
not describe the protocol in any detail here; 
we only highlight its main deficiency. The 
main step of the protocol is for each bridge 
to send a Loop-Detect message that is 
flooded to all the nodes. If the bridge is 
contained in a cycle, then the Loop-Detect 
message returns to it, and it can take the 
appropriate actions. The protocol is correct 
in the sense that all Loop-Detect messages 
will eventually be absorbed and no infinite 
loops can occur. The problem is that for 
some networks, such as the network in 
Figure 3, such flooding generates an ex¬ 
ponential number of messages. There is a 
real danger that so many messages will be 
generated before any of them is absorbed 



Figure 3. Connecting several local area 
networks; the bold lines correspond to 
the spanning tree. 


by the algorithm that the network will be 
swamped and become unusable. The moral 
of this example is that guaranteeing that no 
infinite loops occur is not sufficient; we 
must ensure that not too many messages 
are generated. 

Another example is a protocol for que¬ 
ries in a large network. A node can send a 
query message to other nodes, and they, in 
turn, either answer the query (if they know 
the answer) or forward the query. Suppose 
that each query has a unique identifier and 
that each node remembers the queries it has 
seen. The queries are forwarded, possibly 
in a floodlike manner, throughout the net¬ 
work, but the identifiers are used in an 
absorption algorithm so that a node never 
forwards the same query twice. Suppose 
now that someone is attempting to improve 
the efficiency of the protocol in the follow¬ 
ing way: A query may contain several parts. 
If a node can answer part of the query, it 
does not forward the whole query, only the 
parts that still need to be answered. Sup¬ 
pose that in the implementation the iden¬ 
tifiers of the partial queries are new (which 
is natural since the partial queries are dif¬ 
ferent messages). This cannot cause infinite 
loops because a query with k parts can be 
changed only k - 1 times (it is becoming 
smaller all the time). However, even though 
the number of changes to any query is k - 
1 (and k is probably small), the number of 
possible partial queries is 2* (all subsets of 
at most k parts). So, in the worst case, 2 k 
messages can be generated from one query 
and broadcast to the whole network, an 
unacceptable situation. 

The final example is very different from 
all the rest. It is the Internet “worm” that 
attacked thousands of computers across 
the United States in November 1988 (see 
Spafford 4 ). In this case the “protocol” had 


no useful purpose, and the chain reaction 
may have been initiated intentionally, but 
there is some reason to believe that it was 
not. It could have been caused by sheer 
carelessness, which is what this article is 
meant to prevent. The two characteristics 
of the worm that are of interest to us are that 
it attempted to spread to as many computers 
as possible, and that whenever it established 
itself, it regenerated periodically, making 
it harder for someone to destroy it. This is 
clearly a recipe for a chain reaction. The 
main point is that there was no mechanism 
to limit the number of times a host could 
generate more copies of the worm. Such a 
mechanism is essential in any distributed 
program. 

Detecting and 
preventing chain 
reactions 

The examples shown so far have quite a 
bit in common. This section studies the 
similarities, identifies the “culprits,” and 
suggests ways to prevent such occurrenc¬ 
es. It shows that it is theoretically impos¬ 
sible to prevent all possible failures but 
presents some guidelines to minimize them. 

The common factor in all the examples 
was an infinite or a very large exponential 
loop. The loop consisted of messages— 
control messages, normal messages, or 
broadcast messages—that generated other 
messages. The loops in the examples were 
all results of subtle design failures. The 
first question is whether it is possible to 
detect such loops. Can we somehow ana¬ 
lyze the protocols and find situations that 
can potentially cause loops? Unfortunate¬ 
ly, the answer to this question is no. 

Impossibility of chain reaction detec¬ 
tion. First, let’s define a very simple model 
of distributed computation. There are N 
machines, each executing a local program 
(protocol). The programs are sequential 
with two additional message-passing 
primitives called Send and Receive. A Send 
instruction moves some data to another 
machine (specified in the instruction) and 
deposits it in some buffer in the other 
machine, and a Receive instruction fetches 
messages and acts on them. For simplicity, 
I ignore many issues, such as synchroni¬ 
zation, interrupts, connectivity (assume all 
machines are fully connected to all others), 
and size of the buffers. 

The question addressed is whether it is 
possible to determine, given the programs 


60 


COMPUTER 


















and their inputs, whether the number of 
messages will be finite. The answer to this 
question is negative because this problem 
is equivalent to the halting problem. The 
halting problem is to determine, given a 
(sequential) program and its input, wheth¬ 
er or not the program terminates. This 
problem is undecidable, meaning no pro¬ 
gram can solve it in finite time (see, for 
example, Hopcroft andUllman 5 ). The proof 
that it is impossible to determine whether 
the number of messages is finite follows 
directly from the undecidability of the 
halting problem: 

Theorem 1: Given a distributed program as 
defined above, it is impossible to determine 
whether the number of messages generated 
by the program is finite. 


Proof: Suppose that we had a program P that 
could determine, under the model presented 
above, whether the number of messages is 
finite. We could then use P to solve the halting 
problem. Given a sequential program S for 
which we want to solve the halting problem, 
we insert after every instruction of S a Send 
instruction (to an arbitrary machine). Clearly, 
the number of messages emanating from S is 
finite if and only if S terminates. 

In practice, the fact that the halting 
problem cannot be solved does not severely 
handicap programmers (at least not di¬ 
rectly). We can usually estimate how long 
a program should take, and if the program 
runs too long, we simply stop (kill) it. But 
a major difference between sequential 
computation and distributed computation 
is that it is not easy to stop a distributed 
program that goes berserk. We cannot sim¬ 
ply hit a “kill” button and stop the program 
because many different computers may be 
involved. Furthermore, in many cases the 
only way to access these computers from 
the place that the problem originated is 
through the network. But the network is 
unusable as a result of the problem. That is 
why preventing chain reactions is so im¬ 
portant. 

Similarities of the examples. In the 
Ethernet example the problem was that 
broadcast messages were not identified as 
such and were forwarded. A loop containing 
broadcast messages is obviously much more 
“explosive.” But the heart of the problem 
was the inability of the forwarding proto¬ 
col to realize that it was attempting to 
forward the same message again and again. 

In the next example the loop of mail 
messages was caused by error messages 
generated from other error messages. Again, 


The inherent problem that 
caused the breakdowns is 
automatic generation of 
messages, or AGM. 


the error-handling mechanism was not smart 
enough to detect that the same error was 
being “reported” repeatedly. Notice that in 
this case it was not the same message that 
was forwarded, because each time a new 
error message was generated. 

The problem in the example of loop 
detection in a collection of local area net¬ 
works was not the inability to detect cy¬ 
cles. The algorithm was designed to detect 
all cycles eventually. The problem was 
rather the exponential proliferation of 
messages before the cycles were detected 
and broken. The example shows that in 
some cases even temporary cycles can cause 
a breakdown. 

AGM. The inherent problem that caused 
the breakdowns in these examples is what 
I call automatic generation of messages, or 
AGM. I include in the definition of AGM 
any message generated by a program trig¬ 
gered by a message from another comput¬ 
er. (Variations of this definition are dis¬ 
cussed later.) Thus, forwarding a message 
is an AGM. Using AGM can be highly 
risky, as the examples show, but unfortu¬ 
nately, it is necessary. For example, the 
frequent dissemination of routing infor¬ 
mation cannot be done without AGM, er¬ 
ror messages are always generated auto¬ 
matically, and a .forward file is a very 
convenient feature requiring AGM. How¬ 
ever, AGM makes network protocols very 
vulnerable. Even simple AGM can lead to 
chain reactions. Here is another example: 

A vacation program is a popular pro¬ 
gram that reads one’s mail and automatically 
replies with a message saying something 
like “I am on vacation; I will reply when I 
return.” It is a very easy program to write, 
but, since it is an AGM program, it should 
be written with care (see Allman 6 ). For 
example, if the message generated by the 
vacation program results in an error mes¬ 
sage, then this error message will receive 
the usual vacation reply, and an infinite 
loop will result. A good vacation program 
should remember all addresses to which it 


replied, and it should not reply to those 
again (at least not within a specified peri¬ 
od). Even then, if the program fails to 
recognize the address of the original mes¬ 
sage (conventions for addresses can vary), 
then infinite loops are possible. 

AGM control methods. Methods for 
dealing with AGM are often ad hoc and 
incomplete. The most common method of 
safeguarding against infinite streams of 
messages is aging. Each message has an 
age field, which is incremented periodically 
as the message is forwarded, until the 
message becomes too old. There are several 
variations for deciding when to increment 
the age field. The aging may depend on the 
number of hops the message has taken. If 
the message goes through too many hops, 
it is discarded. This is the method that was 
supposed to prevent the loops of mail 
messages described earlier. Another pos¬ 
sibility is to use the actual time that the 
message was generated and discard the 
message at a later time, when it becomes 
too old in the regular sense of the word. 
This method requires clock synchronization 
and thus may be suitable only for coarse¬ 
grained timing (in minutes, for example). 

In many cases, however, aging is not a 
sufficient safeguard. The main reason that 
the aging process can be circumvented is 
that AGM not only forwards messages but 
often generates totally new messages. A 
new message is almost by definition a 
young message. This is exactly what caused 
the infinite loops of messages in our earlier 
example. The aging process detected the 
original loop, but then an error message— 
newborn as far as the aging process could 
determine—was generated, causing another 
loop. One can argue that error messages 
should be created with the age of the message 
they report on, but that is not so easy. For 
example, an error message reporting that a 
message has reached the bound on the 
number of hops cannot start with the already 
maximal bound on the number of hops; it 
will not get anywhere. Maybe we should 
set the number of hops of that error message 
to be the maximal number minus k, where 
k is a small number (so that we allow k hops 
for this error message). But in that case the 
same infinite loop of messages will occur. 

Relying on time-outs is another common 
approach. If a message does not arrive at its 
destination within a specified time, it is 
discarded (in reliable communication a copy 
of the message is kept, and if an acknowl¬ 
edgment is not received, the message is 
attempted again). Although this approach 
prevents old messages from existing on the 
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network, it does not prevent the creation of 
young messages. Another major drawback 
is that chain reactions that exhibit expo¬ 
nential growth can flood the network faster 
than the time-out, as was described earlier. 

Another approach for preventing infi¬ 
nite AGM is absorption. Messages are al¬ 
lowed to multiply, but they are absorbed 
under some rules. A rule commonly used in 
flooding is to attach an identification number 
to each message and to remember all 
message identifiers. If a message arrives 
twice, it is discarded. The main problems 
with this approach are how to generate the 
identifiers and how long to remember them. 

A relatively safe way to minimize chain 
reactions. By combining the methods just 
discussed, we can obtain an algorithm that 
prevents chain reactions under most cir¬ 
cumstances. Several similar algorithms have 
been suggested (see, for example, Perl¬ 
man 7 ). This algorithm is less specific than 
others in that it addresses all AGMs, not 
only those that occur in the protocols under 
discussion. Because of its generality, it 
may be less efficient than algorithms for 
specific protocols, which can be tuned up. 
But addressing all AGMs is important 
enough to warrant the extra cost. At the 
least, this algorithm can be used as a guide¬ 
line toward the goal of preventing chain 
reactions. 

As noted, AGM is the root cause of chain 
reactions but is essential to network pro¬ 
tocols. We cannot (and do not want to) 
restrict the use of AGM. Also, we cannot, 
in general, distinguish between “bad” 
AGMs (that is, those that cause chain re¬ 
actions) and “good” AGMs. I believe AGMs 
should always be treated as potential chain 
reactions. We have seen examples of chain 
reactions resulting from simple error 
messages and from simple forwarding of 
“lost” messages (which turned out to be 
broadcast messages). Any time a protocol 
includes generating a message as a reply to 
another message, the protocol should be 
tested very carefully. The difficulty is that 
protocols are very complicated and highly 
interrelated. It is sometimes impossible to 
foresee all possibilities. 

If we consider any AGM a possible risk, 
it is clear that we need a general absorption 
algorithm, which will be uniformly applied 
to all AGMs. It is possible, of course, to 
adapt the absorption algorithm to the spe¬ 
cific protocol, and the algorithm may then 
be more efficient, but a general algorithm 
suitable for all protocols is also desirable. 
The following four rules constitute such an 
algorithm. Implementation issues, exten- 


We need a general 
absorption algorithm that 
will be uniformly applied 
to all AGMs. 


sions, exceptions, and relaxations of some 
of these rules are discussed below. 

(1) A unique identifier should be asso¬ 
ciated with every message in the network. 
In some cases there is already enough in¬ 
formation in the message header to serve as 
the identifier (for example, host name, 
sender, and date). 

(2) Whenever a message M 2 is being 
generated as a result of another message 
Mi (in other words, an AGM occurs), then 
the identifier of M 2 should be the same as 
that of M { . (M 2 may include other identifi¬ 
ers as well, but for our purposes, we con¬ 
sider its identifier as that of M x .) This rule 
should hold for every AGM, regardless of 
how simple the protocol is or how infre¬ 
quently it is used. 

(3) The identifiers of all messages for 
which an AGM has occurred in a given 
host should be kept by the host. 

(4) When a message with an identifier 
that exists in the host’s table returns to the 
same host, no further AGM should occur. 

These rules, if implemented correctly, 
are sufficient to prevent chain reactions: 

Theorem 2: Suppose that the rules above are 
maintained by all protocols used in the 
network. Let H be a bound on the total number 
of messages created by hand (that is, by a 
human) in the whole network and L be the 
number of links in the network. Then, the 
total number of messages that can be delivered 
in the network is at most 2 LH. 

Proof: Rule 2 guarantees that all messages 
created by a program have the same identifiers 
as messages created by hand. Therefore, in a 
sense, programs do not create any new 
messages (where “new” indicates new 
identifiers). Every message M that is created 
by hand can be forwarded at most twice along 
any link (once in each direction). The rules 
guarantee that the same node will not forward 
the same message more than once. Hence, the 
total number of messages in the network 
cannot be more than 2 LH. 

These rules may not eliminate chain re¬ 
actions completely, because there is no 


guarantee that they will be implemented 
correctly or that the hardware will be im¬ 
mune to failures. (If the hardware is sus¬ 
ceptible to arbitrary failures, no algorithm 
is safe.) Verifying the correctness of proto¬ 
cols is an extremely difficult problem, which 
is not discussed here. 

The rules may seem inefficient and 
limited for several reasons. First, requiring 
that all messages that ever passed through 
the network be remembered is not reason¬ 
able. This requires too much memory and 
also requires the identifiers to be quite 
large. Fortunately, we can relax the rule to 
state that only the identifiers of messages 
arriving in the last T time units should be 
kept (for example, the last hour). The value 
of T will depend on the speed and size of 
the network. The relaxed rule will not 
prevent chain reactions because infinite 
loops will still be possible, but it will slow 
them down considerably. If T is an hour, 
then each loop can be repeated once an 
hour at most, which minimizes the problem. 
Remembering only recent messages does 
not require too much memory, nor does 
checking for duplication require too much 
of a load. (It is not generally sufficient to 
remember only the last k messages, for some 
small value of k. If the chain reaction in¬ 
volves more than k messages to the same 
host, it may not be prevented.) 

The second problem is the generation of 
identifiers. A message typically passes 
through several layers of protocols, each of 
which is quite independent, and several of 
which may be involved in AGMs. If an 
identifier is generated at a low-level pro¬ 
tocol, the higher-level protocols may not 
be able to recognize the identifier because 
it is part of the message to which they have 
no access. To prevent chain reactions, 
identifiers should be generated as early as 
possible in message creation (for example, 
by the application) and be written in a place 
accessible to all the layers involved in 
AGMs. (It is possible to have identifiers 
for each such layer, although it is not 
necessary.) This requirement may violate 
the modularity and independence of the 
layers, but it is important enough to war¬ 
rant consideration. 

The third problem with the rules is also 
caused by the multitude and independence 
of the protocol layers through which mes¬ 
sages pass. A message that arrives at a 
certain machine may be involved in multi¬ 
ple AGMs by different layers in the same 
machine. The definition of an AGM ap¬ 
plies only to messages from another ma¬ 
chine, but the origin of the message is not 
always easy to determine. If only one table 
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is maintained per host (as suggested in 
rules 3 and 4), then the second AGM in 
the same machine will be stopped by rule 

4. We can avoid this problem either by 
maintaining a table for each layer or by 
not counting as AGM messages that are 
moved in the same machine. 

The fourth problem is that error mes¬ 
sages are severely restricted by rule 4. If 
an error is detected by a node that has 
already participated in the forwarding of 
the message, that node cannot generate 
an error message. This rule can be relaxed 
in the following way: We can define two 
(or more) types of messages: normal 
messages and error messages. An error 
message created as a result of a normal 
message keeps the same identifier, but it 
is labeled an error message. The rules are 
modified to include the types. In partic¬ 
ular, rule 4 now states that a node does 
not forward a message with the same 
identifier and the same type more than 
once. Notice that this rule forbids creat¬ 
ing error messages as a result of error 
messages. 

The fifth problem is the time and space 
required to implement the rules. Some 
protocols, such as routing protocols, rely 
on very efficient implementation and they 
may not afford the extra work. We can 
relax some of the rules, but that will 
increase the possibility of chain reac¬ 
tions. For example, when a message from 
A to B passes through intermediate nodes, 
these nodes may not need to record this 
fact as rule 3 requires. We can think of 
this message as going directly from A to 
B. 

The governing principle behind these 
rules is that they should be applied to all 
protocols. Some protocols already apply 
some (or all) of these rules. For example, 
the Internet Control Message Protocol 
(ICMP), a protocol responsible mainly 
for error messages, does not allow an 
error message to be generated from an 
error message (see Comer 8 ). The vaca¬ 
tion program that is part of the Berkeley 
Unix distribution keeps track of the ad¬ 
dresses it has responded to, and its de¬ 
fault is to send no more than one response 
per address per week. Protocols can be 
interrelated in very complex ways, how¬ 
ever, so it is not sufficient to protect a 
protocol as if it operates in a vacuum. 

The rules pose restrictions on protocol 
design. In some cases a node may need to 
forward the same message, or its rela¬ 
tives, several times. In most of these 
cases one can set a bound on the number 
of forwardings and apply the trick of 


having several (but a small number) of 
message types. Identifying these cases and 
assigning the types is important even if the 
suggested rules are not followed. For ex¬ 
ample, consider the query protocol dis¬ 
cussed in “Additional examples.” Suppose 
that a node tries to send an answer to a 
query back to the originator of the query. If 
that answer message passes through a node 
that participated in the forwarding of the 
query, then, according to our rules, the 
answer should not be forwarded (the an¬ 
swer is an AGM of the query and thus has 
the same identifier). The solution to this 
problem is clear. There should be two types 
of messages, a query and an answer. 

We can relax rule 4 slightly such that 
messages that have already passed through 
the host are not dropped but rather buffered 
for a while (an hour, for example). This 
will remove some of the restrictions (such 
as the restriction against error messages in 
response to error messages), and it will 
limit the speed of possible chain reactions. 
It is essential, however, to check before 
buffering that a message with the same 
identifier is not already buffered. This 
variation of rule 4 can lead to chain reac¬ 
tions, so it should be implemented with 
great care and only as a last resort. 

C hain reactions are unusual, and most 
of the examples presented here were 
caused by improbable sets of events. 
Nevertheless, because the cost of recover¬ 
ing from a network breakdown can be high, 
we should do whatever we can to prevent 
such breakdowns. We cannot foresee all 
possible interactions between network 
protocols, and we cannot hope that the 
probabilities will always work in our fa¬ 
vor. The simple set of rules given in this 
article will prevent most chain reactions. I 
believe that these rules, or variations of 
them, should be incorporated in all net¬ 
work protocols. ■ 
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SPECIAL REPORT 


The 1988-89 Taulbee 
Survey Report 


David Gries and Dorothy Marsh 
Cornell University 


S ignificant findings emerge from 
the 1988-89 Taulbee report, based 
on a December 1989 survey of the 
Forsythe list of computing departments.* * 
The survey focuses on the production and 
employment of PhDs who graduated in 
1988-89** and the faculty of PhD-grant- 
ing computing departments during the 1989- 
90 academic year. All 129 computer sci¬ 
ence departments (117 US and 12 Canadian) 
participated, including 29 of 32 depart¬ 
ments offering the PhD in computer engi¬ 
neering.*** Throughout this report, CE 
statistics are reported separately so that 
comparisons with previous years can be 
made for CS. Nevertheless, we intend to 
merge all statistics for CS and CE within 
the next few years. 

The highlights of the survey are as 
follows: 

• The 129 CS departments produced 625 
PhDs, an increase of 8 percent over the 
previous year. Of the 625 PhDs, 336 were 
American, 35 were Canadian, and 248 were 
foreign (meaning neither American nor 
Canadian). Nearly half, 309, stayed in aca¬ 
demia, 181 went into industry, 24 entered 
the governmental sector, 56 went overseas, 
seven were self-employed, and nine were 



The Computing 
Research Board’s 
survey shows an 
8 percent increase 
in PhDs granted. 
Of the 625 new PhDs, 
none are black, 
six are Hispanic, and 
87 are women. 


unemployed. The employment status of 39 
of the PhDs was not known. 

• 1,215 students passed their PhD qual¬ 
ifying exam in CS departments, an increase 
of 9 percent over 1987-88. 

• No blacks, six Hispanics, and 87 wom¬ 
en received PhDs. 


• The 129 CS departments have 2,550 
faculty members — an increase of 123, or 
nearly one per department. There are 938 
assistant, 718 associate, and 894 full pro¬ 
fessors. 

• The 129 CS departments reported hir¬ 
ing 204 faculty and losing 161 (to retire¬ 
ment, death, other universities, graduate 
school, and nonacademic positions). 

• Six assistant professors in the 129 de¬ 
partments are black, 20 are Hispanic, and 
92 are female. Two associate professors 
are black, six are Hispanic, and 66 are 
female. Four full professors are black, sev¬ 
en Hispanic, and 30 female. 

A number of additional interesting ob¬ 
servations can be made. For instance, al¬ 
though the growth in PhD production to 
625 didn’t reach the expected 650-700, an 
increase of nearly 50 PhDs is substantial. 
This growth made it easier for departments 
trying to hire and more difficult for the new 
PhDs in their job searching. 

There is still a large market. However, 
the new PhDs cannot all expect to be 
placed in the more mature departments, 
and more will take positions in the newer 
departments and the non-PhD-granting 
departments. 


The title of the survey honors OrrinE. Taulbee of the University of Pittsburgh, who conducted the 1970-1984 studies for the Computer Science Board. The CSB is now called 
the Computing Research Board and integrates computer engineering with computer science. 

* The Forsythe list is maintained by the Computing Research Board and includes all departments in the US and Canada that grant a PhD in computer science and computer 
engineering. This is the third year that CE departments have been included in the survey. 

** 156 departments reported on an academic-year basis or did not specify; two reported on a 1989 calendar-year basis. 

*** The departments of computer engineering at the University of Illinois at Champaign-Urbana, Johns Hopkins University, and New Mexico State declined participation 
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Table 1. Department titles. 


No. 

Title 

89 

Computer science(s) 

21 

Electrical and computer 
engineering 

11 

Computer and information 
science(s) 

8 

Computer science and 
engineering 

7 

Electrical engineering and 
computer science 

4 

Electrical engineering 

2 

Computer engineering 

2 

Computing science 

2 

Information and computer 
science 

1 

Advanced computer studies 

1 

Applied sciences 

1 

Computational science 

1 

Computer engineering and 
science 

1 

Computer science and 
electrical engineering 

1 

Computer science and 
operations research 

1 

Electrical, computer, and 
systems engineering 

1 

Electrical engineering and 
computer engineering 

1 

Mathematical and computer 
sciences 

1 

Mathematical sciences 




Growth of PhD production seems to have 
slowed enough so that it does not appear 
that over-production will be a concern in 
the near future. However, there won’t be 
enough retirements to offset new PhD pro¬ 
duction for some 10 years to come. (In the 
158 departments, 22 faculty members died 
or retired last year.) We believe that many 
of the new PhDs would benefit from a year 
or two in a postdoctoral program; perhaps 
this would be the ideal time for the National 
Science Foundation to institute such a 
program in computer science and engi¬ 
neering. 

The percentage of CS PhDs given to 
foreign students remained about the same 
at 40 percent. In CE, the percentage was 
much higher, 64 percent. 

The field continues to be far too young 
— a problem that time alone is slowly 
solving. CS continues to have more assis¬ 
tant professors than full professors — a 
situation that puts an added burden on the 


older people. Nonetheless, there was sub¬ 
stantial growth this year in the number of 
associate professors (as assistant professors 
were promoted). Still, the ratio of assistant 
professors to full professors in CS has not 
changed appreciably in four years. 

As far as we know, no other field has this 
problem, as we have mentioned in previous 
Taulbee reports. In fact, most scientific 
fields are 80- to 90-percent tenured in many 
universities. In CS, this problem is more 
severe at the newer and lower ranked de¬ 
partments. In fact, the top 24 departments 
now have 223 assistant, 176 associate, and 
290 full professors. The CE departments 
have far more full professors than assistant 
professors, mainly because many are older 
EE departments offering CE degrees. 

As indicated above, blacks and Hispanics 
simply are not entering computer science 
and engineering. The time has arrived that 
something be done to rectify this situation. 
We hope the CRB will take the lead in 
introducing programs to encourage more 
participation from these minorities. 

There was slight growth in the percent¬ 
age of female PhDs in CS, to 14 percent 
from 10 percent. Still, there are too few 
women in the field, and our record of re¬ 
tention of women in the faculty is abysmal. 
There are 30 female full professors in the 
158 CS and CE PhD-granting departments. 
As with blacks and Hispanics, we hope the 
CRB will help introduce programs to en¬ 
courage more women to enter computing 
and to remain in academia. There are in¬ 
dications that the NSF is interested in this 
problem as well. 

Methodological comments. Question¬ 
naires were sent to 129 CS PhD-granting 
departments and 32 CE PhD-granting de¬ 
partments in October 1989. (Table 1 lists 
the department titles.) 

The figures in this report are complete 
for CS. The accuracy of the report depends, 
of course, on the accuracy with which the 
questionnaires were filled out by repre¬ 
sentatives of the individual departments. 
Joint EE-CS and EE-CE departments had a 
particularly difficult time completing the 
questionnaires, since they went to the extra 
effort of extracting the CS or CE information 
for their departments. 

As with most surveys, part of the data 
was not filled in or was obviously incor¬ 
rectly entered. We took the liberty to adjust 
some figures and estimate a few others. For 
example, in a few cases, with 156 or 157 
out of 158 departments reporting a figure 
in a field, we estimated that field for the 
others. Our goal was to make this report 


consistent, clear, and simple, without 
modifying the overall results in any way. 

In some instances, we analyzed the data 
for the higher ranked departments as com¬ 
pared to the lower and unranked ones, 
using the 1980 survey done under the aus¬ 
pices of the National Research Council 1 
for ranking. (We also included the two 
largest Canadian universities within the 
top 20.) The NRC survey 1 is now 10 years 
old, and many changes have occurred in 
CS since 1980 (such as the emergence of 
more than 60 PhD-granting CS depart¬ 
ments). Nevertheless, this breakdown still 
provides some useful comparisons. 

To draw meaningful conclusions re¬ 
garding growth of the field (using older 
surveys), from time to time within this 
report we compare figures for the CS de¬ 
partments only, keeping figures for CE 
separate. As stated previously, we will 
combine CS with CE in a few years. 

Throughout the report, figures for 1970- 
84 are taken from O.E. Taulbee, 2 for 1984- 
86 from Gries, 3,4 and for 1986-88 from 
Gries and Marsh. 5,6 It should be further 
noted that the figures for 1970-84 may 
not be accurate because not all depart¬ 
ments completed questionnaires during 
those years. 

Data on students 

PhD production and its growth. The 

field of CS produced 625 PhDs in 1988-89, 
an increase of 48 (8 percent) over 1987-88 
and an increase of 395 (172 percent) over 
1980. Table 2 provides figures on PhD 
production for CS and CE, as well as for 
qualifying-exam passage and sizes of in¬ 
coming classes. In the Table 2 column 
headed “No. of Depts.,” the first number 
represents the departments reporting and 
the second number represents the total of 
known PhD-granting departments. 

As mentioned before, CS PhD produc¬ 
tion increased 8 percent this year, compared 
to 24 percent last year. Future growth is 
expected, but this will probably remain 
under 10 percent per year. The 129 CS 
departments project a 38 percent increase 
next year, but they have always been overly 
optimistic when forecasting PhD produc¬ 
tion. Often, a graduate student appears on 
a department’s list of expected PhDs for 
three years in a row. 

In previous years, estimates of the annu¬ 
al need for new PhDs in CS ranged from 
600 to more than 1,000. This year, for the 
first time, we have surpassed the minimum 
estimate of600. It now becomes even more 
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Table 2. PhD production and its growth. 



Yr. 

No. of 

Depts. 

New 

PhDs 

Per 

Dept. 

Qualifying 

Exam 

Passage 

Per 

Dept. 

New PhD 
Students 

Per 

Dept. 

CS 

1980-81 

_ 

230 


_ 



_ 

CS 

1984-85 

103 (109) 

326 

3.2 

755 

8,2 

1,177 

12 

CS 

1985-86 

117(118) 

412 

3.5 

858 

7.3 

1,170 

10 

CS 

1986-87 

123 (123) 

466 

3.8 

1,008 

8.2 

1,430 

12 

CS 

1987-88 

127 (127) 

577 

4.5 

1,113 

8.8 

1,497 

12 

CS 

1988-89 

129(129) 

625 

4.8 

1,215 

9.4 

1,632 

13 

CS-CE 

1986-87 

145 (156) 

559 

3.9 

1,168 

8.1 

1,621 

11 

CS-CE 

1987-88 

157 (161) 

744 

4.7 

1,399 

8.9 

1,801 

11 

CS-CE 

1988-89 

158 (161) 

807 

5.1 

1,441 

9.1 

1,993 

13 


Table 3. Sex and minority status of the PhDs. 


PhD Minority Status 

CS 



CE 



CS-CE 



Male 

Female 

Total 

Male 

Female 

Total 

Male 

Female 

Total 

White, not Hisp. origin 

330 

62 

392 

90 

14 

104 

420 

76 

496 

Black, not Hisp. origin 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Hispanic 

4 

2 

6 

6 

0 

6 

10 

2 

12 

Other 

204 

23 

227 

66 

6 

72 

270 

29 

299 

Total 

538 

87 

625 

162 

20 

182 

700 

107 

807 


important that we monitor PhD growth as 
well as demand. 

The following explains that real future 
growth will come mainly from the newer 
and smaller two thirds of the departments 
and not the more established one third. 

In 1988-89, an average of 5.1 CS-CE 
PhDs were produced per department (see 
Table 2), with 21 departments producing 
zero, 19 producing one, 24 producing two, 
16 producing three, 12 producing four, and 
14 producing five. Thus, 106 departments 
produced fewer and 52 departments more 
than the average. The 52 that produced 
more than the average — one third of the 
departments — produced 71 percent, or 
more than two thirds, of the PhDs. 

The over-average group of 58 expects to 
increase its PhD production in one year far 
less (by 38, or 10 percent) than the under¬ 
average group (by 179, or 76 percent). 
Either the over-average group does not 
expect to expand much, compared to the 
under-average group, or it is far better at 
predicting PhD-production rates. In either 
case, it is clear that there will be little future 
growth in the over-average departments. 
In successive years since 1984-85, the pre¬ 
dicted one-year growth by the under-aver¬ 
age group was 167 percent, 164 percent, 
116 percent, 82 percent, and 76 percent, 
respectively. 

Sex and minority status. Table 3 gives 


the figures on PhDs awarded to minority 
students and women. The figures are unfa¬ 
vorable from the standpoint of minority 
and female representation in the field. This 
is the case despite the fact that the percent¬ 
age of PhDs going to females did rise to 14 
percent. Table 4 presents statistics for the 
20-year period beginning in 1970, with the 


data before 1984-85 taken from Taulbee. 2 
Throughout the 1980s, the percentage of 
PhDs who are women has remained rela¬ 
tively constant at about 11 percent, those 
who are black at 0.5 percent, and those who 
are Hispanic at 2 percent. 

Citizenship. The number of PhDs given 


Table 4. Sex, minority status, and citizenship of CS PhDs since 1970. 
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Table 5. Employment of the PhDs. 



No. 

of 

PhDs 

Unem¬ 

ployed 

Self- 

Employed 

Academia 

PhD 

Dept. 

Not PhD 
Dept. 

Not CS 
orCE 

Indus¬ 

try 

Govt. 

Outside 
US and 
Canada 

Unknown 

CS 

625 

9 

7 

229 

63 

17 

181 

24 

56 

39 

PCT 

— 

1 

1 

— 

— 

49 

29 

4 

9 

6 

CS-CE 

807 

10 

7 

259 

65 

26 

227 

26 

62 

125 

PCT 


1 

1 

— 

— 

43 

28 

3 

8 

15 


Table 6. Undergraduate and masters degrees. 


Non-PhD Degrees 

PhD Depts. Only 

Undergraduate 





Masters 






84-85 

85-86 

86-87 

87-88 

88-89 

89-90 

84-85 

85-86 

86-87 

87-88 

88-89 

89-90 

CS No. degrees 

10,422 

10,947 

10,540 

10,759 

8,796 

9,037 

2,889 

3,720 

3,614 

4,150 

4,297 

4,444 

No. Depts. Responding 

96 

116 

121 

127 

120 

120 

101 

116 

123 

127 

129 

129 

Ave. Per Dept. 

9 

94 

87 

85 

73 

75 

29 

32 

29 

33 

33 

35 

CE No. Degrees 

— 

— 

2,103 

1,928 

1,810 

1,776 

_ 

_ 

731 

1,009 

1,160 

1,180 

No. Depts. Responding 

— 

— 

22 

30 

26 

27 

— 

_ 

22 

30 

29 

29 

Ave. Per Dept. 

— 

— 

96 

64 

70 

66 

— 

_ 

33 

34 

40 

41 

CS-CE No. Degrees 


— 

12,643 

12,687 

10,606 

10,813 

_ 

_ 

4,345 

5,159 

5,457 

5,624 

No. Depts. Responding 

— 

— 

143 

157 

146 

147 

- 

_ 

145 

157 

158 

158 

Ave. Per Dept. 

— 

— 

88 

81 

73 

74 

- 

- 

30 

33 

35 

36 


Table 7. New graduate students in fall 1989. 



Total New 

With 

PhD 

Masters- 

Part-time 


Graduate 

CS 

Program 

Only 

Masters 


Students 

Degrees 


Program 

Students 

CS Total 

CS Depts. 

3,967 

1,977 

1,632 

2,335 

1,009 

Responding 

CS Ave. 

129 

129 

129 

129 

129 

Per Dept. 

31 

15 

13 

18 

8 

CE Total 

CE Depts. 

1,072 

157 

361 

711 

407 

Responding 

CE Ave. 

29 

29 

29 

29 

29 

Per Dept. 

37 

5 

12 

25 

14 

CS-CE Total 
CS-CE Depts. 

5,039 

2,134 

1,993 

3,046 

1,416 

Responding 
CS-CE Ave. 

158 

158 

158 

158 

158 

Per Dept. 

32 

14 

13 

19 

9 


to foreigners (again, meaning non-Ameri¬ 
cans and non-Canadians) increased by 10, 
although the percentage actually declined 
one point. Table 4 contains figures for 
foreigners from 1970 to 1988. 

Employment. As Table 5 shows, 49 
percent took faculty positions in CS in the 
US or Canada (last year, the figure was 51 
percent). There was little change from 
last year. 


Undergraduate and masters degrees. 

Many universities and colleges have un¬ 
dergraduate and/or masters programs, but 
do not award the PhD. Therefore, the data 
given below says little about the field of 
computer science as a whole. 

Table 6 provides statistics on under¬ 
graduate and masters degrees in PhD de¬ 
partments, with columns labeled “89-90” 
representing expectations. The CS depart¬ 
ments reported a decrease of 18 percent in 


undergraduate degrees. In part, this was 
because several departments did not com¬ 
plete this portion of the survey, although 
the average decrease of 12 undergraduate 
degrees per department is substantial. The 
departments expect an increase again next 
year, but the decrease is still worrisome. 

New graduate students in fall 1989. 

Table 7 gives enrollment figures for new 
students in fall 1989. In the table, “PhD 
Program” stands for the number of new 
graduate students in PhD programs, re¬ 
gardless of whether they intend to earn a 
masters degree first. The number of new 
graduate students in CS decreased 2 per¬ 
cent from last year (to 3,967 from 4,067), 
but the number of new graduate students in 
CS PhD programs rose 9 percent to 1,632 
from 1,497. 

Faculty data 

Table 8 contains statistics on depart¬ 
mental faculty in January 1989. In this 
table, all figures are stated in terms of full¬ 
time equivalents. For example, two half¬ 
time appointments are counted as one full¬ 
time position. 

CS, again, saw little change over the 
previous year in the proportions of faculty 
at the three levels. CS remains a relatively 
young field, with fewer full professors (7.0) 
than assistant professors (7.3) per depart- 
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Table 8. Faculty statistics, 1989-90 academic year. 


Faculty 

All CS-CE Depts. 
(157 of 158 depts.) 

128 of 129 CS Depts. 

Top 24 CS Depts. 

Other 

(104 of 105 depts.) 

Total 

Ave. 

Total 

Ave. 

Total 

Ave. 

Total 

Ave. 

Tenure-Track Faculty 

3,240 

20.6 

2,550 

19.9 

689 

28.7 

1,861 

17.9 

Asst. Prof. 

1,142 

7.3 

938 

7.3 

223 

9.3 

715 

6.9 

Assoc. Prof. 

909 

5.8 

718 

5.6 

176 

7.3 

542 

5.2 

Full Prof. 

1,189 

7.6 

894 

7.0 

290 

12.1 

604 

5.8 

Nonteaching Research Faculty 

171 

1.1 

143 

1.1 

73 

3.0 

70 

0.7 

Postdoctorates 

136 

0.9 

108 

0.8 

60 

2.5 

48 

0.5 

Nontenure-track Teachers 

416 

2.6 

362 

2.8 

74 

3.1 

288 

2.8 

Other Faculty (e.g. visitors) 

237 

1.5 

205 

1.6 

69 

2.9 

136 

1.3 


Table 9. Women and minorities on CS and CE faculties. 



Total 

Women 

PCT 

Blacks 

PCT 

Hispanics 

PCT 

CS Asst. Prof. 

938 

92 

10 

6 

1 

20 

2 

CS Assoc. Prof. 

718 

66 

9 

2 

0 

6 

1 

CS Full Prof. 

894 

30 

3 

4 

0 

7 

1 

CS Total 

2,550 

188 

7 

12 

0 

33 

1 

CE Asst. Prof. 

204 

11 

5 

3 

1 

4 

1 

CE Assoc. Prof. 

191 

8 

4 

0 

0 

2 

1 

CE Full Prof. 

295 

3 

1 

1 

0 

1 

0 

CE Total 

690 

22 

3 

4 

0 

7 

1 


ment. However, we are seeing a gradual 
change as the field matures. The top 24 
departments have a larger per-department 
number (12.1) of full professors than assis¬ 
tant professors (9.3). 

Women and minorities. At the request 
of Nancy Leveson of the University of 
California at Irvine, we added a new ques¬ 
tion to the 1988-89 survey concerning the 
number of women, blacks, and Hispanics 
in the PhD-granting computing depart¬ 
ments. Table 9 provides the bleak statistics 
derived from the question. 

That the numbers of blacks and Hispan¬ 
ics in our faculties are so low was no 
surprise — since 1973, less than 1 percent 
of our PhDs have been black or Hispanic. 
Thus, you can’t expect to have more than 1 
percent of blacks and Hispanics as faculty 
members. Blacks and Hispanics must be 
attracted into our field at a much lower 
level — in our high schools and colleges. 

For women, however, the results are 
gloomy in another way. The numbers are 
fine at the assistant-professor level in that 
the percentage of women (10 percent) is 
the same as the percentage in PhD produc¬ 
tion (10-12 percent since 1973 and 14 per¬ 
cent this year). But, at the associate- and 
full-professor levels, the percentages of 
women fall drastically to 9 percent and 3 
percent, respectively, indicating that we 
are not retaining women as faculty mem¬ 


bers over the years. At the professorial 
level, there aren’t enough women for one 
per department. In toto, there are scarcely 

1.5 women per department. (Leveson has 
analyzed the plight of women in comput¬ 
ing in detail in a report written for Erich 
Bloch, director of the NSF.) 

Hiring for 1988-89. CS-CE depart¬ 
ments reported hiring 259 new faculty, or 

1.6 per department. CS departments in the 
US hired 180, or 1.4 per department. Sala¬ 
ries were reported for new PhDs hired for 
fall 1989 by 75 US CS-CE departments, 62 
US CS departments, and 10 Canadian de¬ 
partments. Table 10 provides this salary 
information. The data for the Canadian 
universities is shown separately in Canadi¬ 
an dollars. It should be noted that Canadian 
salaries are on a 12-month scale, that Cana¬ 


dian and US dollars command different 
values, and that the typical amounts of 
consulting that can be performed in the two 
countries differ. 

The average US salary for a new PhD 
increased from $36,668 in fall 1985 to 
$38,957 in fall 1986 (6.2 percent) to $40,885 
in fall 1987 (4.9 percent) to $42,653 in fall 
1988 (4.3 percent) to $44,946 in fall 1989 
(5.0 percent). 

Table 11 lists the number of CS-CE 
departments averaging salaries in each 
$1,000 range for fall 1989 and four previ¬ 
ous years (the numbers are rounded and 
presented in thousands of dollars). 

Faculty salaries. Table 12 summarizes 
nine-month faculty salaries in US CS and 
CS departments during the 1988-89 aca¬ 
demic year. The second column of Tables 


Table 10. New PhD salaries for fall 1989. 



All US 

CS-CE Depts. 

All US 

CS Depts. 

Top 24 US 

CS Depts. 

Other 103 US 
CS Depts. 

12 Canadian 

CS Depts. 

Total Hired 

259 

180 

43 

137 

24 

No. Depts. Reporting Salaries 

75 

62 

19 

43 

10 

Minimum 

$39,000 

$39,000 

$42,500 

$39,000 

$34,970 

Average (of the averages) 

$44,946 

$44,985 

$45,381 

$44,810 

$44,519 

Maximum 

$56,650 

$56,650 

$49,000 

$56,650 

$48,340 


October 1990 


69 















Table 11. Number of departments with new US PhD salaries 1985-86 through 1989-90. 


Salaries* 35 36 37 38 39 40 41 42 43 44 45 46 47 


49 50 51+ 


1985- 86 

1986- 87 

1987- 88 

1988- 89 

1989- 90 


13 14 20 


'* In thousands of doll 


Table 12. Nine-month salaries, 135 of 146 US CS and CE departments. 


Faculty 


Reported Minimums 


Average 

Reported Maximums 


Rank 

No. 

Min 

Mean 

Max 

Over All 

Min 

Mean 

Max 

Asst. 

Assoc. 

Full 

993 (1,061) 
752 (809) 
960(1,070) 

$27,200 

$28,300 

$36,000 

$42,762 

$47,583 

$57,338 

$51,000 

$61,000 

$83,040 

$45,634 

$52,669 

$68,699 

$37,018 

$44,035 

$51,000 

$48,970 

$57,940 

$83,802 

$65,970 

$85,000 

$135,000 

Table 13. Nine-month salaries, 

109 out of 117 US CS departments. 





Faculty 


Reported Minimums 


Average 

Reported Maximums 


Rank 

No. 

Min 

Mean 

Max 

Over All 

Min 

Mean 

Max 

Asst. 

Assoc. 

Full 

812 (857) 

594 (618) 

717 (775) 

$27,200 

$28,300 

$36,000 

$42,828 

$47,848 

$57,996 

$49,000 

$61,000 

$83,040 

$45,679 

$53,094 

$69,326 

$37,018 

$44,035 

$54,300 

$48,985 

$58,430 

$84,236 

$57,800 

$74,325 

$135,000 

Table 14. Twelve-month salaries, 12 of 12 Canadian CS departments (i 

n Canadian dollars). 



Faculty 


Reported Minimums 


Average 

Reported Maximums 


Rank 

No. 

Min 

Mean 

Max 

Over All 

Min 

Mean 

Max 

Asst. 

Assoc. 

Full 

81 (81) 

100 (100) 
119(119) 

$36,952 

$42,930 

$56,885 

$45,999 

$52,703 

$65,881 

$53,000 

$64,202 

$73,000 

$49,178 

$59,383 

$76,560 

$42,793 

$51,376 

$73,904 

$52,188 

$69,132 

$88,826 

$65,830 

$107,000 

$115,104 


Table 15. Desired faculty growth. 



1989- 

1990 

1990- 

1991 

1991- 

1992 

1992- 

1993 

1993- 

1994 

1994- 

1995 

5-Yr. 

Increase 

CS Faculty Size 

2,573 

2,774 

2,919 

3,040 

3,145 

3,240 

25 % 

CS Ave. Size 

20.1 

22.5 

23.6 

25.6 

24.0 

25.3 

_ 

CS-CE Faculty Size 

3,281 

3,521 

3,698 

3,844 

3,965 

4,075 

24% 

CS-CE Ave. Size 

21.0 

22.4 

23.5 

24.5 

25.2 

26.0 

- 


12 to 14 gives the number of faculty (in 
each rank) for which salaries were reported 
and, in parentheses, the total number of 
faculty in that rank. 

Departments reported the minimum, 
mean, and maximum salaries of assistant, 
associate, and full professors and the num¬ 
ber of faculty in each rank. For minimum 
salaries (as well as maximum), the table 
shows the minimum, average, and maxi¬ 


mum. The average is given over all salaries 
in each faculty rank. This is not the average 
of the means, but the true average. 

Comparing this year’s CS figures with 
last year’s, we found that the average assis¬ 
tant professor’s salary increased 4 percent 
from $43,959 to $45,679, the average asso¬ 
ciate professor’s salary rose 5 percent from 
$50,806 to $53,094, and the average full 
professor’s salary grew 3 percent from 


$67,205 to $69,326. 

Forty-six US departments reported a 
maximum full-professor salary of greater 
than $90,000. 

Table 14 gives salary information for the 
12 Canadian departments. 

Estimates of department growth. The 

departments were asked to estimate their 
faculty sizes through 1994-95, given an 
adequate supply of applicants. The 158 
CS-CE departments would like to grow by 
794 (24 percent) by 1994-95. The 128 CS 
departments would like to grow by 667 to 
3,240 (25 faculty per department). 

Last year, 127 CS departments reported 
a desire to grow from 2,477 (19.5 per 
department) to 2,684 (21.1 per department). 
However, this year they report growing 
less than half as much, to 20.1 per depart¬ 
ment. Except for the six largest depart- 
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Table 16. Faculty losses. 



CS-CE Depts. 


CS Depts. 



With PhD 

Without PhD 

Total 

With PhD 

Without PhD Total 

Died or Retired 

22 

7 

29 

14 

4 

18 

Were Visitors, Returned to Employers 

17 

0 

17 

15 

0 

15 

Teaching Elsewhere 

76 

4 

80 

63 

4 

67 

Left for Nonacademic Positions 

49 

3 

52 

44 

3 

47 

Returned to Graduate School 

0 

1 

1 

0 

1 

1 

Other 

21 

2 

23 

12 

1 

13 

Total 

185 

17 

202 

148 

13 

161 


ments. Table 15 indicates that all depart¬ 
ments desire roughly the same growth, 
regardless of size. 

Faculty losses. Table 16 gives statistics 
on faculty losses. The CS departments re¬ 
ported losing 0.7 percent of the faculty 
through death and retirement; and the CE 
departments, 1.1 percent. We don’t expect 
higher percentages of retirement in CS for 
another 5-10 years. Of the other 173 CS¬ 
CE faculty who left, at least 35 percent left 
for other teaching positions, 26 percent left 
academia, 13 percent were visitors who 
returned to their employers, and 3 percent 
returned to graduate schools. The percent¬ 
ages for CS were very similar: 35 percent, 
teaching elsewhere; 27 percent, positions 
outside academia; 14 percent, visitors; and 
3 percent returned to graduate school. This 
year, 161 faculty left the departments; last 
year the figure was 179. ■ 
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User interface management systems and application portability 

Robert C. Seacord, Software Engineering Institute 


Higher level programming languages 
and standard operating systems now pro¬ 
vide greater portability of application 
software than previously possible. Soft¬ 
ware developed in C for Unix, for ex¬ 
ample, can be easily ported to a variety 
of different architectures and machines. 
Developing language and operating sys¬ 
tem standards such as ANSI C and IEEE 
Posix will further application portability. 

At a quick glance, open systems are, at 
long last, apparently becoming a reality. 
But, is this really the case? 

As porting software to different archi¬ 
tectures becomes more and more a matter 
of simply recompiling the software for 
that architecture, a serious problem is ap¬ 
parent in portability with the user inter¬ 
face of these systems. Now, more than 
ever, a customer buying a computer plat¬ 
form is also buying a “look and feel” as¬ 
sociated with that system. 

When using an Apple Macintosh, for 
example, the user expects to be able to 
perform a variety of actions using a sin¬ 
gle-button mouse. When working with an 
MS-DOS application, the user expects to 
be able to perform the same actions using 
the keyboard. When running Open Look, 
Motif, or Next Step, the user expects the 
application to provide a defined look and 
feel. Porting an application to simply run 
on a different platform is insufficient; the 
application interface is required to be¬ 
have much like it does with other appli¬ 
cations developed for that environment. 

Software designs are usually not ex¬ 
tensible enough to allow the integration 
of different user interface toolkits, par¬ 
ticularly if these toolkits employ signifi¬ 
cantly different models in their applica¬ 
tion interfaces. Changing toolkits or 
integrating new toolkits usually requires 
major application modification, which 
then requires extensive retesting of the 
application. 

Current standards activities are just be¬ 
ginning to address this problem. To date, 
standards bodies have attempted to de¬ 
fine an abstract user interface toolkit that 
can be implemented in different ways. 
Where this approach provides some de¬ 


gree of device independence, it does not 
allow for the removal of stylistic con¬ 
cerns from the application. For example, 
where one user interface style guide may 
call for a pull-down menu, another may 
call for a command line interface. 

One approach for addressing this prob¬ 
lem of application portability across mul¬ 
tiple platforms is the definition and im¬ 
plementation of a method for separating 
the application from the user interface. 
This separation makes changing the user 
interface of the system practical and 
makes changing user interface toolkits 
without modifying the application soft¬ 
ware possible. 

User interface management systems. 

The term user interface management sys¬ 
tem was coined at the 1982 Workshop on 
Graphical Input Interaction Technique 
(GUT). 1 Among other things, UIMSs are 
intended to encourage the separation of a 
software system into an application por¬ 
tion and a user interface portion. The ap¬ 
plication portion of a system implements 
the core functionality, while the user 
interface portion implements the user 
interface dialogue. 

UIMSs provide facilities for defining 
both presentation and the computer-hu¬ 
man dialogue components of a user inter¬ 
face. A UIMS also may provide facilities 
to support prototyping, encourage a de¬ 
sign that allows for easy modification of 
the user interface, support implementa¬ 
tion and maintenance of the user inter¬ 
face, and allow for the incorporation of 
new user interface technologies. 

Most UIMSs are based on the Seeheim 
architecture 2 (see Figure 1). This archi¬ 
tecture uses a layered approach similar to 
the one used in the International Stan¬ 
dards Organization (ISO) Open Systems 
Interconnection (OSI) model. The archi¬ 
tecture is intended to encourage the sepa¬ 
ration of functionality between the appli¬ 
cation and the user interface portions of a 
software system. 

The three different layers of the archi¬ 
tecture provide differing levels of control 
over user input and system output: 


The application layer consists of the 
core functionality of the application that 
can be described in a presentation-inde¬ 
pendent manner. For example, in a calcu¬ 
lator program, this would include the 
underlying math subroutines library. 

The dialogue layer specifies the pre¬ 
sentation-dependent portion of an appli¬ 
cation system including the dynamic be¬ 
havior of the user interface. The dialogue 
should allow the display and removal of 
interaction objects without application 
involvement and support cascading 
menus, direct manipulation, and other 
user interface styles and techniques. The 
dialogue provides the mapping between 
the presentation and application layers. 
The user interface dialogue may be 
specified via a user interface definition 
language (UIDL) or by an interactive 
technique. 

The presentation layer controls the 
end-user interactions and generates low- 
level feedback. The presentation layer 
consists of a collection of interaction ob¬ 
jects defined for a given user interface 
technology. 

Existing approaches. Since the 1982 
GUT Workshop, a number of efforts 
have been undertaken to build UIMSs 



Figure 1. User interface management 
system architecture. 
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that achieve the goal of separation of 
concerns, while remaining a practical ap¬ 
proach to software development. These 
systems have been classified by the mod¬ 
el used in dialogue specification. Some 
of the more successful approaches have 
been 

• event-driven, 

• declarative, 

• object-oriented, 

• data-driven, and 

• interactive layout systems. 

In the event-driven approach, inputs 
are considered as events that are immedi¬ 
ately handled by event handlers. Event 
handlers can cause output events, change 
the internal state of the system, and call 
application routines. Examples of event- 
driven systems include the University of 
Alberta UIMS, 3 ALGAE, 4 Sassafras, 5 
and the Tele Use UIMS. 6 

Another approach is the use of de¬ 
clarative languages in which constraints 
are defined to specify what the system 
should do rather than how it should be 
done. An example of a system that takes 
this approach is Cousin. 7 In this catego¬ 
ry, a class of systems exists that automat¬ 
ically generates the user interface based 
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on a definition of the semantic com¬ 
mands supported by the application. Ex¬ 
amples are the UofA* UIMS 8 and 
MIKE. 9 

An object-oriented approach uses ob¬ 
jects for defining user interactions, trans¬ 
forming data, and interacting with the 
application. A good example of a com¬ 
mercially available system that uses an 
object-oriented approach is Open Dia¬ 
logue, 10 developed by Apollo Computer. 

In the data-driven approach, the appli¬ 
cation communicates with the UIMS in 
terms of shared data elements. The 
UIMS behaves like an active database in 
that it provides a mapping between appli¬ 
cation data and user interface toolkit ob¬ 
jects, and notifies the application of 
changes to application data resulting 
from user interactions. This approach 
was implemented in the Serpent UIMS 11 
developed at the Software Engineering 
Institute at Carnegie Mellon University 
and the George Washington UIMS. 12 

Interactive layout systems allow the 
user to build a user interface by direct 
manipulation. Examples are Menulay, 13 
Dialog Editor, 14 vu, 15 and TAE+. 16 

UIMS study group. The IEEE PI201 
working group was formed in January 
1989 and chartered to develop standards 
that would further application and user 
portability in the X Windows Environ¬ 
ment. 17 Since P1201 was formed, the 
Open Software Foundation, Sun, and 
AT&T have independently developed 
toolkits for X Windows. Much of the 
PI201 effort has been spent trying to de¬ 
cide if any of these toolkits can serve as 
a basis for a standard or if a “virtual” 
toolkit approach can be used. 

In August 1989, a UIMS study group 
was initiated in P1201 to determine if 
UIMS technology was sufficiently ad¬ 
vanced to solve the problem of applica¬ 
tion portability across multiple platforms 
with different look-and-feel fields and to 
define the scope of a UIMS standard. 

The group identified two components 
whose standardization would be benefi¬ 
cial to the industry. The first of these is 
an application programmers’ interface 
that would 

(1) provide a standard application pro¬ 
grammers’ interface across changes in 
the underlying toolkit; 

(2) support the separation of an appli¬ 
cation into presentation-independent and 
presentation-dependent layers corre¬ 
sponding to the application, dialogue, 
and presentation layers of the Seeheim 
architecture; and 

(3) allow the development of applica¬ 
tions that are independent of presenta¬ 
tion; for example, the underlying win¬ 
dowing system or user interface toolkit. 


The second component is a UIMS 
interchange format. The purposes of a 
standard UIMS interchange format are to 

(1) enable a wide variety of UIMSs to 
use a single format to store and exchange 
data, and 

(2) allow vendors to develop compil¬ 
ers or interpreters that could “execute” 
the UIF on their platforms in a manner 
analogous to Postscript printers. 

The PI201 UIMS study group has 
evaluated a number of user interface 
management systems including Serpent, 
Tele Use, and TAE+. The consensus of 
the group is that the state of the practice 
is sufficiently advanced to warrant a 
standards effort. It is believed that a 
UIMS standard would enhance both ap¬ 
plication portability and the state of the 
practice in user interface development. 
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Nominations sought for 
two TAG posts 

Nominations are being accepted for 
the 1991 chair and vice chair positions 
on the Technical Advisory Group of the 
Joint Technical Committee/Subcommit¬ 
tee 7, United States International Stan¬ 
dards Organization/International Electro¬ 
technical Commission. The US SC7 
TAG coordinates the US position on 
international software engineering stan¬ 
dards. 

The names of interested and qualified 
candidates should be submitted to Bob 
Pritchard, IEEE Standards Office, 445 
Hoes Lane, PO Box 1331, Piscataway, 
NJ 08855-1331. 

Nominees should have employer sup¬ 
port to enable those elected to properly 
to carry out their TAG responsibilities. 

The election will take place at the De¬ 
cember 13-14 SC7 TAG meeting in San 
Diego, California. 

The IEEE Computer Society provides 
administrative support to the TAG. 
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Computer Society chapter formed in Moscow 


The most recent addition to the grow¬ 
ing list of IEEE Computer Society chap¬ 
ters is the Moscow Chapter, which re¬ 
ceived official approval effective August 
15, 1990. The interim chair is Nikolai V. 
Sazonov, pending election of officers. 

An IEEE section, a prerequisite for 
the formation of a Computer Society 
chapter, was formed at the same time, 
with 65 members. “The simultaneous 
section and chapter formation is indica¬ 
tive of strong Soviet interest in computer 
technology,” said Computer Society 
President Helen Wood, “and in the shar¬ 
ing of technical progress across former 
barriers.” 

The IEEE reports that Romania has 


successfully concluded a 13-year-long 
effort to form an IEEE section and that 
Czechoslovakia is also working to estab¬ 
lish a section. 

According to Michel Israel, chair of 
the Computer Society’s European Activi¬ 
ties Committee, the Moscow Chapter 
was created through the cooperative ef¬ 
forts of his committee, the USSR Minis¬ 
try of Education, and the Popov Society 
(named for Aleksandr Stepanovich Pop¬ 
ov, an early pioneer in the field of radio). 
Some of the top computer scientists in 
the USSR — academicians, directors of 
well-known institutes, and engineers — 
are included in the new chapter’s mem¬ 
bership, Israel said. 


Benefits of Computer Society chap¬ 
ter status include participation in the 
Distinguished Visitors Program and the 
Chapters Tutorials Program, and sup¬ 
port on conferences, workshops, and 
publications from both the Area Activi¬ 
ties Board and the Computer Society 
staff. 

The total number of Computer Society 
chapters now exceeds 130. In addition, 
the society has more than 120 student 
branch chapters. Besides the Moscow 
Chapter, new chapters have been formed 
during 1990 in El Salvador, Guatemala, 
Northern Italy, Indonesia, Venezuela, 
and Western Puerto Rico, and in Mem¬ 
phis and Kansas City in the US. 


95 programs now accredited by Computer Science 
Accreditation Commission 


Fourteen programs have been added to 
the accreditation list this year by the 
Computer Science Accreditation Com¬ 
mission, bringing the total to 95. The 
CSAC accredits baccalaureate computer 
science programs designed to prepare 
graduates for entry into the computer sci¬ 
ence profession. Programs accredited by 
CSAC meet or exceed the Computing 
Sciences Accreditation Board and the 
CSAC’s criteria requirements for faculty, 
curriculum, laboratory and computing 
resources, students, and institutional 
support. 

The accreditation process requires that 
the institution submit a comprehensive 
self-study of the program, and includes a 
campus visit by a CSAC evaluation team. 

The Computing Sciences Accredita¬ 
tion Board was founded in 1984 by the 
ACM and the IEEE Computer Society in 
response to concerns about quality, con¬ 
sistency, and professional outcomes for 
graduates of computer science programs. 

The 95 programs currently accredited 
by CSAC are listed below, followed by 
the year of initial accreditation. Unless 
otherwise stated, all programs are for the 
bachelor of science degree in computer 
science. 


For more information about the ac¬ 
creditation process, including a copy of 
“CSAC/CSAB Criteria for Accrediting 
Programs in Computer Science in the 
United States,” call or write to Patrick 
M. LaMalva, Executive Director, Com¬ 
puting Sciences Accreditation Board, 

345 East 47th St., New York, NY 10017; 
phone (212) 705-7314, e-mail 
lamalva@um.cc.umich.edu. 


Alabama 

Auburn University, Auburn (1987) 
University of Alabama, Huntsville 
(1988) 

University of Alabama, Tuscaloosa 
(1990) 

University of South Alabama (1988) 
BS computer and information sci¬ 
ence; computer science specializa- 


Arkansas 

University of Arkansas, Little Rock 
(1990) 

California 

California Polytechnic State Univer¬ 
sity, San Luis Obispo (1986) 


California State University, Chico 
(1987) 

Options: general; math/science; sys- 

California State University, Fullerton 
(1988) 

California State University, Northridge 
(1987) 

California State University, Sacra¬ 
mento (1986) 

California State University, San Ber¬ 
nardino (1990) 

California State University, Stanislaus 
(1986) 

University of California, San Diego 
(1986) 

University of California, Santa Bar¬ 
bara (1986) 

BS and BA computer science 
University of San Francisco (1987) 
University of Southern California 
(1988) 

University of the Pacific (1990) 
Colorado 

United States Air Force Academy 
(1986) 

University of Colorado, Colorado 
Springs (1989) 
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Connecticut 

Central Connecticut State University 
(1990) 

District of Columbia 

American University (1987) 

George Washington University (1987) 
Howard University (1988) 

BS systems and computer science 

Florida 

Florida State University (1987) 
University of Central Florida (1989) 
University of North Florida (1987) 

BS computer and information sci¬ 
ence; specialization in computer sci¬ 
ence 

University of South Florida (1989) 
Georgia 

Georgia Institute of Technology 
(1986) 

BS information and computer sci- 


Illinois 

Illinois Benedictine College (1989) 
Indiana 

Ball State University (1987) 

BS or BA computer science (with or 
without co-op education) 

Iowa 

Iowa State University (1986) 

Louisiana 

Louisiana Tech University (1988) 
Northeast Louisiana University (1987) 
Southern University (1989) 

Scientific option 
Tulane University (1990) 

University of New Orleans (1987) 
University of Southwestern Louisiana 
(1987) 

Maryland 

Loyola College in Maryland (1990) 
United States Naval Academy (1987) 

Massachusetts 

Brandeis University (1986) 

BA computer science 
Northeastern University (1986) 
Southeastern Massachusetts University 
(1988) 

University of Lowell (1990) 

Worcester Polytechnic Institute (1986) 

Michigan 

Oakland University (1988) 

Western Michigan University (1986) 
Theory and analysis option 


Minnesota 

St. Cloud State University (1989) 


University of Minnesota, Duluth 
(1989) 

Missouri 

Southwest Missouri State University 
(1989) 

University of Missouri, Rolla (1986) 
Mississippi 

Mississippi State University (1986) 
University of Mississippi (1990) 
University of Southern Mississippi 
(1987) 

New Hampshire 

University of New Hampshire (1987) 


South Carolina 

Clemson University (1986) 
University of South Carolina (1990) 
Winthrop College (1990) 

Texas 

Baylor University (1987) 

Texas Christian University (1990) 
University of Houston, University 
Park (1987) 

University of North Texas (1986) 
University of Texas, El Paso (1986) 

Utah 

Brigham Young University (1989) 
University of Utah (1986) 


New Mexico 

New Mexico State University (1988) 
University of New Mexico (1988) 

New Jersey 

Fairleigh Dickinson University (1987) 
Teaneck Campus 

New Jersey Institute of Technology 
(1986) 

Stevens Institute of Technology (1986) 
New York 

Canisius College (1987) 

College of Staten Island, CUNY 
(1989) 

Pace University (1986) 

Polytechnic University (1988) 
Rochester Institute of Technology 
(1989) 

State University of New York, Albany 
(1987) 

State University of New York, Bing¬ 
hamton (1989) 

State University of New York, Platts¬ 
burgh (1988) 

North Carolina 

Appalachian State University (1988) 
North Carolina State University (1987) 

North Dakota 

North Dakota State University (1986) 
University of North Dakota (1987) 
BA/BS computer science 

Ohio 

Marietta College (1989) 

Wright State University (1987) 

Oklahoma 

University of Tulsa (1988) 

Pennsylvania 

Allegheny College (1986) 

Drexel University (1986) 

Lehigh University (1987) 

Program offered in College of Engi¬ 
neering and Physical Science 
University of Scranton (1990) 


Virginia 

Hampton University (1989) 

Old Dominion University (1990) 
Virginia Commonwealth University 
(1988) 

Washington 

Eastern Washington University (1987) 
Pacific Lutheran University (1989) 
Western Washington University 
(1987) 
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Microprocessor industry scrutinizes engineer’s patent 


Bob Carlson, Staff Editor 

With potentially huge sums in royal¬ 
ties at stake, attorneys for Intel and other 
microprocessor manufacturers have been 
poring over the patent recently issued to 
Gilbert P. Hyatt of La Palma, California, 
for the invention of the microprocessor. 
Hyatt’s successful bid for a patent on 
technology he claims to have devised in 
1968 climaxed a 20-year effort by the en¬ 
gineer and inventor. 

Hyatt, a member of the IEEE and 
ACM, says that he began work on the in¬ 
vention early in 1968 and built his first 
working computer later that year. He 
formed Micro Computer, Inc., the same 
year with the intent of developing the 
microcomputer technology. The compa¬ 
ny folded after about three years. Hyatt 
applied for the parent patent on Decem¬ 
ber 28, 1970. 

Intel actually produced the first com¬ 
mercial microprocessors the following 
year, but Hyatt never gave up pursuing 
the recognition he believed he deserved. 
“I needed financial support,” Hyatt was 
quoted as saying in a Reuter wire service 
dispatch. “I suspect that’s how my tech¬ 
nology filtered down to the marketplace.” 

Millions of dollars in the balance. 

There has been much speculation but lit¬ 
tle in the way of specifics about what 
Hyatt might ultimately reap as a result 
of his patent. The Washington Post's 
Evelyn Richards pointed out that Hyatt 
would not be able to claim infringement 
on any chips made before his patent was 
issued, but he could attempt to collect 
royalties on products sold during the next 
17 years. 

With so much at stake, a protracted 
David-and-Goliath struggle appears cer¬ 
tain, and analysts seem reluctant to pre¬ 
dict how the spoils are likely to be di¬ 
vided. 

Hyatt, who has more than 50 other pat¬ 
ents to his credit, works independently as 
an aerospace consultant, engineer, and 
inventor. He is optimistic about the pres¬ 


ent climate for innovation and has ex¬ 
pressed a desire to plow his potential 
gains back into more high-tech R&D 
projects. 

Lengthy inquiry predicted. Patent 
and copyright attorney Richard H. Stern, 
who writes a regular column in IEEE 
Micro on patent and copyright law, has 
not seen the patent but commented on the 
basis of published reports. Since Hyatt 
refiled several times with the patent of¬ 
fice during his 20-year battle, Stern said, 
his applications will have to be examined 
carefully to make sure he wasn’t simply 
reacting to ongoing progress in the field. 
“The concern is to what extent he kept 
adding things and making changes as he 
went along,” Stern said. “It’s not a free 
ride.” 

During the years that Hyatt spent mak¬ 
ing additional filings with the patent of¬ 
fice, other significant patents were being 
issued for similar devices. So timing as 
well as the content of his applications be¬ 
comes an issue in sorting out Hyatt’s po¬ 
sition. Most observers anticipate a lengthy 
and arduous investigation. 


The National Institute of Standards 
and Technology (NIST) Center for 
Manufacturing Engineering has joined 
the Applied Physics Laboratory of Johns 
Hopkins University in a one-year re¬ 
search program to achieve productivity 
and quality improvements in computer- 
integrated manufacturing systems. Sur¬ 
face-mount printed circuit boards are 
typical of the products targeted. 

The project will include the specifica¬ 
tion of process and quality control tech¬ 
niques and strategies, computer hardware 


Challenge to the patent process. The 

20-year time frame and the surprise that 
Hyatt’s patent generated throughout the 
industry led one columnist to question 
the entire patent process and its ability to 
keep pace with the rapid growth of tech¬ 
nology. “If even an abstract of Hyatt’s 
application had been released 24 months 
after filing 21 years ago, semiconductor 
companies would have had an inkling of 
what was going on,” wrote Michael 
Schrage in the Los Angeles Times. “They 
could have rushed their own applications 
or sought to cut a deal with the young in¬ 
ventor.” 

Schrage contrasted the US system, in 
which patent applications are sealed until 
the patent is awarded, with the procedure 
in Japan and Europe, where patent appli¬ 
cations are made public 18 months after 
filing. 

As the industry moves into months — 
perhaps years — of inquiries and legal 
maneuvers, one thing seems certain: A 
high-profile case such as this will turn up 
the volume in the ongoing discussion of 
how to establish, protect, and profit from 
intellectual property rights. 


and software, data requirements, and in¬ 
terface and support standards such as the 
standard for the exchange of product 
model data and the Defense Dept.’s com¬ 
puter-aided acquisition and logistic sup¬ 
port standards. In addition, new concepts 
for process control sensors will be tested. 

The cooperative research project 
draws on NIST skill in process control 
sensors, automation, and standards tech¬ 
nology, and the Applied Physics Lab’s 
expertise in applications and electronics 
manufacturing. 


Research program seeks to improve CIM systems 
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IEEE takes position on computer crime 


The United States Activities compo¬ 
nent of the IEEE has adopted a position 
on computer crime stating, in part, that 
existing legislation may not be clear and 
comprehensive enough to address all the 
problems of computer crime. Well-craft¬ 
ed federal legislation is recommended to 
promote uniform treatment of computer 
crime across the nation and provide sig¬ 
nificant deterrence as well as punish- 

According to the IEEE, such legisla¬ 
tion should 

• distinguish deliberately malicious 
acts from accidents; 

• avoid imposing overly specific and 
burdensome operating requirements 
on computer systems operators, 
manufacturers, or users; 

• cover a broad range of computer 


Students selected for awards in the 
1991-1992 National Science Foundation 
graduate fellowship competition, con¬ 
ducted for NSF by the National Research 
Council, will receive stipends of $13,500 
for a 12-month fellowship tenure. The 
cost-of-education allowance to the insti¬ 
tution chosen by the fellow for graduate 
study will be $6,000 in lieu of all tuition 
costs and assessed fees. This year’s com¬ 
petition will continue the special Women 
in Engineering component to encourage 
women to undertake graduate study in 
engineering fields. 

NSF plans to award about 900 new 
three-year graduate fellowships to indi¬ 
viduals who have demonstrated ability 
and special aptitude for advanced train¬ 
ing in science or engineering. To in¬ 
crease the number of practicing scientists 
and engineers who are members of ethnic 
minority groups that have been under¬ 
represented in the advanced levels of the 
nation’s science and engineering talent 
pool, approximately 200 fellowships will 
be offered in the NSF minority graduate 
fellowship program. 

The graduate fellowships are intended 
for students in the early stages of gradu¬ 
ate study. Applicants are expected to 
take the Graduate Record Examination 
(GRE). The examinations will be given 
December 8, 1990, at designated centers 
throughout the United States and in cer¬ 
tain other countries. NSF will pay the 
test fees for fellowship applicants, pro¬ 
viding NSF application is the primary 
purpose. 


crimes and techniques and not be 
tool specific; and 

• recognize trespass within an infor¬ 
mation system as a criminal act with¬ 
out requiring the system owner or 
operator to show that there has been 
damage or the potential to do damage. 

Furthermore, the IEEE says that the 
law should not be written in a way that 
would discourage research on or discus¬ 
sion of the technology of malicious 
codes. Research into such techniques is 
an essential part of legitimate efforts to 
understand and control the threat of com¬ 
puter crime. 

For more detailed information about 
the IEEE position on this issue, contact 
IEEE Public Relations, 1828 L St., N.W., 
Suite 1202, Washington, DC 20036- 
5104. 


The deadline for submission of appli¬ 
cations to both the graduate fellowship 
program and the minority graduate fel¬ 
lowship program is November 9, 1990. 
Further information and application ma¬ 
terials can be obtained from the Fellow¬ 
ship Office, National Research Council, 
2101 Constitution Ave., Washington, DC 
20418. 


The University of California at San 
Diego and the San Diego Supercomputer 
Center have acquired a 32-processor 
iPSC/860 parallel computer from Intel 
Scientific Computers in Beaverton, Ore¬ 
gon. The iPSC/860 is built around Intel’s 
i860 microprocessor, a RISC chip con¬ 
taining more than one million transistors. 

Scientists from UCSD’s Computer Sci¬ 
ence and Engineering Computing Facility 
will help create software for the system, 
as well as compilers capable of translating 
programs created for traditional comput¬ 
ers for use on parallel systems. 

The system, with a speed of nearly 2 
billion floating-point operations per sec¬ 
ond, is a result of the Touchstone project, 
a three-year effort being carried out by 
Intel with the help of a $7.6 million grant 
from DARPA. The Touchstone project, 
launched in April 1989 with a total ex- 


DoE shares risk- 
assessment methods 

Security controls that cost more than 
the information they protect are not cost- 
effective. Thus, an important part of de¬ 
veloping a computer security program is 
weighing the cost of controls against the 
risk of loss. 

As part of its investigation into ways 
to identify risk and choose appropriate 
computer security measures, the National 
Institute of Standards and Technology 
(NIST) is offering information on meth¬ 
ods developed by other federal agencies. 

NIST recently reprinted a publication 
describing the risk assessment method 
used by the US Department of Energy. 
Steps specified in the DoE approach 
include 

• defining the system, software, 
and data; 

• identifying threats; 

• selecting countermeasures; and 

• obtaining management review, 
participation, and accountability. 

The publication includes worksheets 
and tables needed to carry out each step, 
along with a sample completed work 
sheet, a bibliography, and a glossary. 

US Department of Energy Risk Assess¬ 
ment Methodology (NISTIR 4325) is 
available from the National Technical 
Information Service, Springfield, VA 
22161. Order by PB #90-244484 for $23 
prepaid. 


pected cost of $27.5 million, calls for a 
2,048-processor machine with peak 
speeds of 150 gigaflops by 1992. The ul¬ 
timate goal is a teraflop by 1995. 

A report from the President’s Office of 
Science and Technology Policy calls for 
a major jump in supercomputing perfor¬ 
mance to help solve some extremely dif¬ 
ficult problems. These include world cli¬ 
mate prediction, semiconductor circuit 
design and test, superconductivity re¬ 
search, mapping of the human genome, 
and support for advanced drug design. 

Federal science officials have con¬ 
cluded that the best way to reach these 
scientific goals is through parallel super¬ 
computers. The National Science Foun¬ 
dation is encouraging the four supercom¬ 
puter centers it sponsors, one of which is 
SDSC, to become involved in parallel 
computing. 


NSF raises graduate fellowship stipend 


Parallel computing to tackle big problems 
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RTSS-90 

Eleventh Real-Time Systems Symposium 

December 4-7, 1990 
Orlando, FL 


Sponsors: 

the Computer Society of the IEEE 
TC Real-Time Systems 


Scope: All aspects of the design, development, and analysis of real-time systems 
General Chair: Dr. Doug Locke, IBM 

General Program Chair: Professor Jane W.S. Liu, University of Illinois 


Tuesday, December 4 

Tutorial: “Rate-Montonic Scheduling Theory: Practical Applications",Lui Sha, Carnegie Melleon University and Doug Locke, IBM Federal Sector Div. 
This tutorial focuses on the application of the rate monotonic scheduling (RMS) theory. The tutorial begins with an introduction to the theory, and 
addresses typical concerns regarding the practicality of the theory. For further information on the tutorial contact Linda Buss, address below. 


Wednesday, December 5 

On-site registration and check-in (coffee and pastries) 

Welcome 

Session 1: Scheduling and Resource Allocation I 

- Minimizing the Number of Late Tasks with Error Constraints, 


Session 6: Operating System 

- The ARTS Real-Time Object Model, C.W. Mercer, H. Tokuda 

- Time Capsules: An Abstraction for Access of Continuous-Media Data, 

R. G. Herrtwich 

- Incremental Garbage Collection of Concurrent Objects, 

D.M. Washabaugh and D. Kafura 


d. Y-1. Leung, u.o. vvong 

- Resource Reclaiming in Real-Time, 

C. Shen, K. Ramamritham, J. A. Stankovic 

- Scalability of a Distributed Real-Time Resource Center, 
N. Griffeth, A. Weinrib 

Session 2: Experimental Systems and Tools 

- Implementing a Verifier for Real-Time Systems, 

D. A. Stuart 

- Experiments with a Program Timing Tool Based 
on Source-Level liming Schema, 

C.Y. Park, A. C. Shaw 

- From CHAOS™ to CHAOS arc : A Family of 
Real-Time Kernels, K. Schwan, A. Gheith, H. Zhou 
Session 3: Concurrency Control and I/O Scheduling 

- Dynamic Real-Time Optimistic Concurrency Control 
J. R. Haritsa, M. J. Carey, M. Livny 

- Concurrency Control in Real-Time Databases by 
Dynamic Adjustment of Serialization Order, Y. Lin 

S. H. Son 

- Scheduling I/O Requests with Deadlines a 
Performance Evaluation, R. Abbott, H. Garcia-Molina 

Thursday, December 6 
Session 4: Communication 

- On-Une Routing of Real-Time Messages, J. Y-T. Leung, 

T. W. Tam, G. H. Young 

- Analytic Evaluation of Contention Protocols Used for 
Real-Time Systems, K.G. Shin, C. Hou 

- Real-Time Communication in Multiple Token Ring 
Networks, Y-H. Lee and L-T. Shen 


Session 7: Scheduling and Resource Allocation II 

- The Preemptive Scheduling of Sporadic, Real-Time Tasks on One 
Processor, S.K. Baruah, A.K. Mok, L.E. Rosier 

- A Stack-Based Resource Allocation Policy for Real-Time Processess, 
T.P. Baker 

- Fixed Priority Scheduling of Periodic Task Sets with Arbitrary Deadlines 
J.P. Lehoczky 

Special Session: Current Work 

Short presentations: Symposium participants are invited to present their 
on-going work. 


Friday, December 7 
Session 8: Case Studies 

- Real-Time System Scenarios, J. Molini, S. Maimon, P. Watson 
-The ATAMM Data-Flow Architecture, S. Som, R.R. Mielke, 

J.W. Stoughton 

Session 9: Language Support 

- Structuring Real-Time Systems with Performance Polymorphism, 
K.B. Kenny, K.J. Lin 

- Applying Compiler Techniques to Scheduling in Real-Time Systems, 
P. Gopinath, R. Gupta 

- Language Support for Maruti Real-Time System, V.M. Nirkhe, 

S.K. Tripathi, A.K. Agrawala 

- MRL: A Real-Time Rule-Based Production System, C-K. Wang, 

A. K. Mok, A.M.K. Cheng 


Session 10: Semantics 

- A Calculus for Communicating Systems with Time and Probabilities, 
H. Hansson, B. Jonsson 

-A Proof System for Communicating Shared Resources, R. Gerber, 


Specifying and Verifying a Real-Time Priority Queue with Modal 
Algebra, v. Yokaiken, 1C Ramamritham 


Session 5: Fault Tolerance 

- New Latency Bounds for Atomic Broadcast, R. Strong, 

D. Dolev, F. Cristian 

- Agreeing on a Leader in Real-Time, B.A. Coan, G. Thomas 

- A Robust Group Membership Algorithm for Distributed 
Real-Time Systems, P. D. Ezhilchelvan, R. Lemos 


Session 11: Architecture 

- A Tagged Memory Technique for Recovery from Transient Errors in 
Fault-Tolerant Systems, S.J. Adams, T. Sims 

- SMART (Strategic Memory Allocation of Real-Time) Cache Design, 
D.B. Kirk, J.K. Strosnider 

- Real-Time Computing Supports in Futurebus+, L. Sha, J. Lehoczky, 
R. Rajkumar 


For hotel reservations contact 
Walt Disney World Dolphin 
1500 EPCOT Resort Blvd. 

Lake Buena Vista, FL 32830 
1-800-227-1500 

(Be sure to request the conference rate: $130) 
(Room rate only good until 11/18/90, after 
that date the price will increase.) 

For more information contact: 

Linda Buss 

Dept. Mathematics/Computer Science 

Macalester College 

1600 Grand 

St. Paul, MN 55105 

(612)696-6287 
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Organization 


City/State/Zip. 
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Mail registration forms to: 11th RTSS-90 
do Linda Buss (address at left) 

Registration Advanced 

Fee (before 11-18-90) (after 11-18-90) 
IEEE Member 190 230 

Non-Member 240 290 

Full-Time Student 70 90 


IEEE Member #_ 


Check here if you do not wish to have 
your name and address published in 
the list of attendees._ 


Tutorial 
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Non-Member 


170 

215 


210 

260 
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Postscript output on a Laserjet printer 

T. L. (Frank) Pappas, AWEB Software Technology 


Postscript output devices let you print 
a wide variety of typefaces in various 
sizes as well as graphics for producing 
books, reports, viewgraphs, brochures, 
etc. But what if you don’t have a Post¬ 
script printer? These printers cost signifi¬ 


Postscript with TeX 

In the August 1989 issue, I reviewed 
TeX on the IBM PC and described the 
standard Computer Modern fonts avail¬ 
able with TeX. But there are also two 
TeX approaches for producing Postscript 
output. 

If you’re interested in TeX, look at 
TeX for the Impatient by Paul Abrahams 
et al., published by Addison-Wesley. It’s 
both a good introduction to TeX and a 
good reference, so even experienced TeX 
users will like it. It won’t replace Donald 
Knuth’s The TeX Book (published by 
Addison-Wesley) as the final authority, 
but it’s enough for most people. For $10, 
you can get a diskette containing the well- 
documented macros used in the book. 

PC TeX 3.0 

Knuth recently made some upward- 
compatible enhancements to TeX — 
making it version 3.0 — and is urging 
everyone to upgrade. Typical users won’t 
use most of the enhancements, but macro¬ 
package writers might. For example, 
there’s now a way to control the error 
messages TeX produces, so that errors 
can be described in terms of the macro 
package. 

For users writing in languages other 
than English, the enhanced hyphenation 
features and 8-bit character support will 
make TeX better suited to their needs. 
TeX’s ligature support has also been im¬ 
proved. 

PC TeX, from Personal TeX, is one of 
the first PC versions to support version 
3.0. This outstanding product comes in 
three flavors. PC TeX ($249) runs on an 


cantly more than HP Laserjet-compatible 
printers. 

In this review, I look at three ap¬ 
proaches to producing Postscript output 
on a Laserjet printer, using the Laserjet 
IIP. If you want more information about 


XT, AT/286, or AT/386. PC TeX/386 
($295) runs on any AT/386 with at least 
2 Mbytes of memory. Big PC TeX/386 
($349) runs on any AT/386 with at least 
4 Mbytes of memory. 

Capacity limits of earlier versions 
have increased. For example, font memo¬ 
ry has increased by 28 percent for all 
three versions. Page and memory capaci¬ 
ty has quadrupled for Big PC TeX/386 
and doubled for the other two. The maxi¬ 
mum number of TeX commands has in¬ 
creased by 233 percent for Big PC TeX/ 
386 and by 66 percent for the other two. 

To give you an idea of relative speeds, 
I ran two chapters (43 pages) of a book 
I’m writing through the three versions. 
Big PC TeX/386 produced the .dvi file in 
1 minute, 20 seconds, PC TeX/386 in 1 
minute, 52 seconds, and PC TeX in more 
than 5 minutes. 

In TeX, external fonts are related to 
internal names through font declarations. 
For example, “/tenrm=cmrl0” associates 
the name “tenrm” with Computer Mod¬ 
ern Roman at 10 points. Fortunately, 

TeX’ style files contain definitions for 
commonly used fonts. 

Figure 1 shows Postscript output pro¬ 
duced with PC TeX. To use New Centu¬ 
ry Schoolbook, I changed the font decla¬ 
rations, as in “/tenrm=psmncsr.” Here, 
“psmncsr” is the name of the Postscript 
New Century Schoolbook Roman font 
used by Arbortext’s Postscript driver. 

With the number of font names typi¬ 
cally used in TeX — LaTeX has pre¬ 
defined about 50 — redefining each one 
would be annoying. Nelson Beebe, presi¬ 
dent of the TeX Users Group, sent me a 
preliminary collection of style files that 


Postscript, the standard references are 
from Adobe Systems, published by Addi¬ 
son-Wesley: The Postscript Language 
Reference Manual, Postscript Language 
Program Design, and The Postscript 
Language Tutorial and Cookbook. 


do the renaming for you. Including the 
line “/input psmncs” in a TeX or LaTeX 
document redefines these names. (You 
can reach the TeX Users Group at PO 
Box 9506, Providence, RI02940-9506.) 

PC TeX is the best version of TeX for 
the PC. If you have a 386 and the neces¬ 
sary memory, you’ll be better off buying 
PC TeX/386 or Big PC TeX/386. Person¬ 
al TeX is at 12 Madrona Ave., Mill Val¬ 
ley, CA 94941, phone (415) 388-8853. 

Reader Service 21 

DVI Laser/PS 

TeX creates a device-independent .dvi 
file that is printed or viewed using a 
driver program (I detailed this process in 
the August 1989 issue). For Postscript 
output, DVI Laser/PS, from Arbortext, is 
the driver I like. 

Figure 1 shows that a TeX document 
can include text and Postscript graphics 
if the driver supports it. It also illustrates 
that different Postscript fonts can be used 
in the same document. 

In many ways, DVI Laser/PS is like 
DVI Laser/HP for the Laserjet printers, 
which I reviewed in the August issue. In 
fact, it’s the one I use when I print TeX 
documents on a Laserjet. In this review, 
I’ll just concentrate on a few of the Post¬ 
script support features. 

Postscript graphics are inserted via the 
“/special” command. DVI Laser/PS’s 
version has several subcommands: 
epsfile inserts encapsulated Postscript 
files; plotfile inserts non-EPS files, such 
as the palette in Figure 1; overlay prints 
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The palette of shades of gray below is taken from the PostScript 
Language Reference Manual. Text in this paragraph is written in Com¬ 
puter Modern 10-point. Here is some bold text. 



Text in this paragraph is written in the PostScript font Avant 
Garde Book for 10-point roman, and Avdnt Garde Demi for 10- 
point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font New 
Century SchoolBook Roman for 10-point roman, and New Century 
Schoolbook Bold for 10-point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font Times Roman for 
10-point roman, and Times Bold for 10-point bold. Here is some bold text. 


Figure 1. Postscript output from PC TeX using DVI Laser/PS. 


Text in this paragraph is written in Computer Modern 10-point. 
Here is some bold text. 

Text in this pdragraph is written in the PostScript font Avant 
Garde Book for 10-point roman, and Avdnt Gdrde Demi for 10- 
point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font New 
Century SchoolBook Roman for 10-point roman, and New Century 
Schoolbook Bold for 10-point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font Times Roman for 
10-point roman, and Times Bold for 10-point bold. Here is some bold text. 


Figure 2. AP-TeX fonts from the HP Laserjet IIP. 


a border, letterhead, etc. on each page of 
output; rotate lets you rotate a TeX box 
through a given angle; and revbar and 
revpoint draw revision bars in the margin. 

The PC version of DVI Laser/PS sells 
for $225. It’s also available for other 
computer systems. If you want to use 
TeX with Postscript output, get DVI 
Laser/PS. Arbortext is at 535 W. William 
St., No. 300, Ann Arbor, MI 48103, 
phone (313) 996-3566. 
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AP-TeX fonts 

One problem with using Postscript with 
TeX is the reduced portability of generat¬ 
ed documents. With Computer Modern 
fonts you can pass a TeX source file to 
any TeX user and get the same output re¬ 
gardless of the TeX version or printer be¬ 
ing used. With some exceptions, the 
same is true for the .dvi file. Introducing 
Postscript removes this portability. 

AP-TeX fonts from Kinch Computer, 
helps solve this problem. TeX uses .tfm 
font metric files to produce a .dvi file; a 
driver uses .pk font files to produce a file 
you can send to a printer. The AP-TeX 
fonts are a collection of .tfm and .pk files 
that provide Postscript-equivalent fonts 
in many sizes. In contrast, DVI Laser/PS 
uses .tfm files but produces a Postscript 
file. 

AP-TeX supports the 35 Postscript 
fonts found on an Apple LaserWriter. 

They are provided in 5, 6, 9, 10, 11, 12, 
14.1, 17.3, 20.7, and 24.9 point sizes. 
Helvetica Bold, Palatino Bold, and 
Times Bold also have headlines sizes of 
29.9, 35.8, 43.0, 51.6, 61.9, and 74.3 
points. Even though only a fixed number 
of sizes are available, they should be 
enough for most uses. 

There are some limitations when using 
the AP-TeX fonts. Figure 2 is the text of 
Figure 1 produced with AP-TeX on the 
Laserjet IIP. The palette is not included, 
since Postscript graphics cannot be pro¬ 
duced using the fonts. However, the pal¬ 
ette can be included by using a Postscript- 
to-PCL translator and including the PCL 
version using the “/special” command. 
Also note that the text in Figure 1 looks a 
little better — for example, look at “writ¬ 
ten” in the Times Roman paragraphs. 

If you want Postscript capabilities with 
TeX while keeping some portability, the 
AP-TeX fonts may be for you. For $200, 
they are worth it. It would be nice if these 
fonts were as widely available as the 
Computer Modern fonts. You can reach 
Kinch Computer at 501 S. Meadow St., 
Ithaca, NY 14850, phone (607) 273-0222. 
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Postscript in software 

Now I’ll look at some software prod¬ 
ucts that let you print Postscript output 
on a Laserjet-compatible printer. I dis¬ 
cuss hardware and software performance 
issues later in the section titled “Post¬ 
script in hardware.” 


Freedom of Press 

Freedom of Press lets you produce 
Postscript output on a wide variety of 
non-Postscript printers. This software 
Postscript interpreter is from Custom Ap¬ 
plications, 900 Technology Park Drive, 
Bldg. 8, Billerica, MA 01821, phone 
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(800) 873-4367. It provides the 35 scal¬ 
able fonts found on an Apple LaserWriter 
and interprets Postscript graphics. 

I produced Figure 3 using Freedom of 
Press on a Laserjet IIP. This may be a 
good substitute if you don’t have a Post¬ 
script printer, but you can see problems 
in the output, particularly in Figure 3’s 
last paragraph in “10-point roman”; the 
letters in “roman” are squeezed a little 
bit too close together, and the letters “r,” 
“m,” and “n” have stubs at the top. 

Freedom of Press can be run as a resi¬ 
dent program so that an application can 
write directly to a Postscript printer, with 
Freedom of Press capturing its output 
and printing directly to your printer. For 
programs like DVI Laser/PS that create a 
Postscript file. Freedom of Press can be 
invoked at the DOS command line. 

In addition to the actual printers that 
Freedom of Press supports, it includes a 
special “printer” named PCX-File-200 


that lets the program create 200-dpi PCX 
files. 

As a software solution for Postscript 
output. Freedom of Press would make 
good sense at $495, but its poor perfor¬ 
mance (detailed below) makes it useless. 
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Goscript Plus 

This software Postscript interpreter 
from Lasergo supports the same fonts 
and graphics as Freedom of Press but is 
not nearly as reliable. For example, I 
couldn’t print Figure 1 using Goscript. 
When I tried, I got two error message 
from the interpreter. The first, “Current 
point not defined,” occurred for each .dvi 
file I tried, but normally it would let me 
continue. The second, “Bad operand 
type,” made the interpreter fail. To make 


matters worse, it left behind two of its 
temporary files. 

I sent a copy of the Postscript output 
for Figure 1 to Lasergo, so maybe they 
will fix it. I used the new version (ver¬ 
sion 3), but the problem also occurs in 
version 2.1 hope the product’s reliability 
gets better, because it has a number of 
nice features. For example, Goscript sup¬ 
ports a Postscript viewer that displays a 
full page of text on the screen so you can 
get an idea of what the final output will 
look like. This is especially useful for 
placing graphics such as the palette of 
Figure 1. 

I was able to produce a version of 
Figure 1 by staying with the Computer 
Modern fonts. When I displayed the 
output on the screen, everything was 
properly placed, but only the upper half 
of the palette was filled in. The outline of 
each petal was visible, but the petals in 
the bottom half were filled in white. 
However, when Goscript produced out¬ 
put for the Laserjet, the palette looked 
fine. 

For $299, this would be a really nice 
product if it were more reliable. It sup¬ 
ports a wide range of printers and is con¬ 
siderably faster than Freedom of Press. 
You may be able to use it successfully 
with your products, but unless Lasergo 
will let you return it if it doesn’t work 
with your applications. I’d wait for the 
next release. Lasergo is at 9235 Trade 
Place, Suite A, San Diego, CA 92126, 
phone (800) 451-0088. 
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Hijaak PS 

In the August 1989 issue I also re¬ 
viewed Hijaak from Inset Systems. Hi¬ 
jaak is a program that converts between 
various file formats. Inset has teamed up 
with Lasergo for a special version of Hi¬ 
jaak, called Hijaak PS, that converts 
Postscript files to the formats used by PC 
fax cards, such as JT Fax, The Complete 
Fax, and many others. 

Hijaak PS, for $249, includes version 
1.1C of Hijaak and version 2.20 of Go- 
script (which only has 13 fonts). For 
$150 you can upgrade to version 3.0 of 
Goscript Plus. With the upgrade, you get 
Postscript output for your printer or fax, 
and Hijaak’s great file-conversion capa¬ 
bility. The one negative feature of Hijaak 
PS is Goscript’s unreliability. However, 
once that problem is corrected, this hy¬ 
brid product will be an excellent buy. 

You can contact Inset Systems at 71 
Commerce Drive, Brookfield, CT 06804, 
phone (800) 828-8088. 
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The palette of shades of gray below is taken from the PostScript 
Language Reference Manual. Text in this paragraph is written in Com¬ 
puter Modern 10-point. Here is some bold text. 



Text in this paragraph is written in the PostScript font Avant 
Garde Book for 10-point roman, and Avant Garde Demi for 10- 
point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font New 
Century SchoolBook Roman for 10-point roman, and New Century 
Schoolbook Bold for 10-point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font Times Roman for 
10-point roman, and Times Bold for 10-point bold. Here is some bold text. 


Figure 3. Postscript output using Freedom of Press. 
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Postscript in hardware 

Another way to turn your Laserjet 
printer into a Postscript printer is to use 
a Postscript emulation cartridge that 
plugs into one of your printer’s font- 
cartridge slots. The Pacific Page Personal 
Edition cartridge from Pacific Data Prod¬ 
ucts is for the Laserjet IIP, but the com¬ 
pany also makes cartridges for other 
Laserjet printers. 

Figure 1 was produced using Pacific 
Page. One thing I really like about this 
cartridge is the consistent quality of the 
output and its reliability. I tried several 
complicated graphics, all of which print¬ 
ed flawlessly. Pacific Page also perfectly 
emulated the 35 scalable Postscript 
fonts. 

The cartridge works by executing code 
out of a cartridge slot. The code is the 
Phoenix Page Postscript Interpreter from 
Phoenix Technologies. To use this car¬ 
tridge you need 2.5 Mbytes of printer 
memory — the .5 Mbytes that’s standard 
with the IIP and 2 Mbytes more. 

I used Pacific’s 2 Plus 2 memory 
board for the additional memory. It was 
easy to put in, but its construction pre¬ 
vented me from plugging in my generic 
1-Mbyte memory board. However, Pacif¬ 
ic claims that it will work with most oth¬ 
er memory boards. The 2 Plus 2, which 
can also be used in a Laserjet III, lists 
for $595. It consists of 16 1-Mbit 120-ns 
DRAMs. 

I also have Pacific’s 25 in One font 
cartridge that provides 172 fonts and 
symbols sets compatible with 25 Laserjet 
cartridges. The 25 in One can be used in 
a Laserjet II, IID, IIP, or III. With the 25 
in One you don’t have to change car¬ 
tridges to use different fonts. This is es¬ 
pecially important with the IIP, which 
has only one cartridge slot. (The HP’s 
single slot also prevents you from using 
both Pacific cartridges at once, but that’s 
Hewlett-Packard’s design decision, not 
Pacific’s, matched only by HP’s soaking 
you $195 for a paper-feed tray.) Pacific 
also supplies drivers for such popular 
products as Windows, Pagemaker, Word, 
WordPerfect, Lotus 1-2-3, Excel, and 
Ventura Publisher. For $499, this car¬ 
tridge is a must if you use applications 
that produce Laserjet output. 

To get an idea of Pacific Page’s per¬ 
formance, I ran some tests, which are 
summarized in Table 1. For the mixed 
graphics of Figure 1, Pacific Page and 
Freedom of Press each took about 2.5 
minutes to print one page, while Goscript 
failed. But when I created a TeX file that 
repeated this figure on four pages, the 
last three pages printed much faster than 
the first. 

To get full pages of text only, I re¬ 


Table 1. Postscript-emulation performance. 



Pacific Page 

Freedom 
of Press 

Goscript 

PCL 

mixed(l) 

2:24 

2:28 

Failed 


mixed(4) 

4:45 

6:08 

Failed 


text(l) 

2:11 

10:01 

4:12 

0:41 

text(4) 

5:08 

33:11 

10:57 

1:24 


moved the figures and extra white space 
from a copy of this review and used DVI 
Laser/PS to print first one page, then 
four pages. Pacific Page’s numbers 
aren’t too different from the first test, but 
Freedom of Press’ results are horrible. 
Goscript took twice as long as Pacific 
Page in both text cases, which is OK for 
software emulation. 

I then contrasted Pacific Page’s perfor¬ 
mance with that of the IIP by running the 
text case in native PCL mode. Pacific 
Page took twice as long to print one page 
as native PCL mode, but 3.3 times as 
long for four pages. Since Postscript re¬ 
quires considerably more processing, it’s 
not surprising that PCL native mode was 
faster. If the printer had 4 Mbytes of 


Including illustrations 

Once you have Postscript capability 
you’ll want to include illustrations in 
your documents. You might want to use 
a scanner to get the illustrations, or you 
might want to use a drawing program to 
create them. 

The Complete Page Scanner 

In keeping with the low cost of the 
Postscript alternatives already reviewed, 

I looked at a low-cost scanner from The 
Complete PC (521 Cottonwood Drive, 
Milpitas, CA 95035, phone (408) 434- 
0145). For $899, The Complete Page 
Scanner is definitely complete. 

The 13x9.5-inch scanner uses sheet 
feeding rather than a flat bed. It can scan 
images up to 8.5x14 inches and can scan 
at 200 or 300 dots per inch. Black-and- 
white or halftone imaging is provided. 
The latter supports four or eight shades 
of gray and can use either Bayer, mesh, 
or spiral dithering. Settings are selected 
from the front control panel. 

Smartscan, the software provided with 
the scanner, simplifies much of the scan¬ 
ning and image use, rivaling software 
I’ve seen with more powerful scanners. 


memory, I doubt the ratio would be as 
high. 

You can switch between PCL and 
Postscript modes. The 25 in One can’t be 
used in PCL mode, since the printer must 
be turned off before removing or insert¬ 
ing the Pacific Page cartridge, but you 
can switch modes without removing the 
cartridge. 

At $499, Pacific Page is fast enough, 
especially if you can’t afford a Postscript 
printer. Pacific Data Products is at 9125 
Rehco Road, San Diego, CA 92121, 
phone (619) 552-0880. 

Pacific Page: Reader Service 27 
25 in One: Reader Service 28 
2 Plus 2: Reader Service 29 


For example, you can easily merge 
scanned images, as I did in creating Fig¬ 
ure 4. First, I scanned Figure 1 as black- 
and-white text and used Smartscan’s 
cropping and erasing functions to keep 
the text and palette in separate images. 
Next, I wrote the text that appears below 
the palette on a piece of paper and 
scanned it as a black-and-white image. 

Once I had the three images, I used the 
Page function to paste them together. Us¬ 
ing a mouse, I moved each image where 
I wanted it and hit the FI0 key to freeze 
the image. Before positioning the palette 
and handwritten text, I used the Rotate 
function to rotate the images. The hand¬ 
written text was too big for the remain¬ 
ing space, so I used the Size function to 
reduce it. 

While the scanned text looks pretty 
good, the palette isn’t as good. I purpose¬ 
ly picked an example that would show 
you how the scanner handles the worst 
case, an image in which adjacent sections 
do not contrast much. This lack of con¬ 
trast is particularly noticeable in the up¬ 
per right of the palette. When scanning 
images with reasonable contrast, the 
scanner produced reasonable results, es¬ 
pecially for an $899 scanner. 
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The palette of shades of gray below is taken from the PostScript 
Language Reference Manual. Text in this paragraph is written in Com¬ 
puter Modern 10-point. Here is some bold text. 



Text In this paragraph is written in the PostScript font Avant 
Garde Book for 10-point roman, and Avant Garde Demi for 10- 
polnt bold. Here is some bold text. 

Itext in this paragraph is written in the PostScript font New 
Century SchoolBook Roman for 10-point roman, and New Century 
Schoolbook Bold for 10-point bold. Here is some bold text. 

Text in this paragraph is written in the PostScript font Times Roman for 
10-point roman, and Times Bold for 10-point bold. Here is some bold text. 


Figure 4. A version of Figure 1 scanned and altered using The Complete Scanner 
and Smartscan software. 


Smartscan offers several other capabil¬ 
ities that make it very useful — such as 
image scaling from 10-200 percent, 
printing scanned images, and pixel edit¬ 
ing of scanned images — but the one that 
really stands out is its conversion capa¬ 
bility. 

Scanned images can be converted to 
standard graphics formats: CUT, MSP, 
IMG, PCX, TIFF, and both high- and 
low-resolution formats for The Complete 
Fax. With the exception of TIFF, these 
formats can also be converted to the for¬ 
mat used by Smartscan. Moreover, 

ASCII text and Epson FX graphics can 
be included. Smartscan also allows you 
to import files created by most popular 
word processors. 

I’ve used the scanner to scan my com¬ 
pany letterhead and include it on the cov¬ 
er page of every fax that I send. I have a 
JT Fax (which is now made by Hayes), 
so I converted the scanned image to PCX 
and used the JT Fax software to include 
it in the cover page. 

To convert a scanned image to Post¬ 
script, I convert it to PCX and use Hijaak 


to convert it to Postscript. This lets me 
include scanned images in my Postscript 
documents. 

I like this compact scanner, even 
though I prefer flat bed scanners to those 
with sheet feeders. But for $899, this 
scanner is enough for most people’s 
needs. 
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Adobe Illustrator 

Another way to include Postscript 
graphics in your Postscript documents is 
to use a drawing program such as Adobe 
Illustrator ($495). This fine program pro¬ 
vides all the tools you need to create 
great graphics. A companion product, 
Adobe Streamline ($395) converts bit¬ 
mapped images in PCX, TIFF, or PNT 
(Macpaint) format to Postscript for Illus¬ 
trator, or to the formats for Corel Draw 
or Micrografx Designer. 

Both products require Windows/286 or 
386, although they come with a runtime 


version. A mouse is required. While a 
Postscript printer is recommended (one 
of the hardware or software interpreters 
already reviewed will do), you can use a 
Laserjet compatible to get draft quality 
output. 

I really like Illustrator and Streamline, 
but before I tell you why, I want to men¬ 
tion a few problems. Illustrator does not 
yet execute under Windows 3.0. Adobe 
is working on a 3.0 version, but no re¬ 
lease date has been announced. Adobe 
does say that the retail price of the Win¬ 
dows 3.0 version will be the same as the 
current version. 

Under Windows/286 (and the runtime 
version), you must use an expanded 
memory manager. I have one that lets me 
use extended memory as expanded mem¬ 
ory, but it doesn’t work with Windows. 

I also experienced some performance 
problems with Windows/386.1 called 
Adobe for some advice, but what they 
told me to do just made things worse. 
Adobe promised to get back to me after 
my second call, but they never did. 

The installation of both products 
should be changed. Illustrator tries to 
take you through all possible Windows 
installations in one set of combined in¬ 
structions, forcing you to skip around 
sections that don’t apply. This creates a 
maze of instructions that makes it easy to 
miss information. I had to redo the entire 
installation because I missed something 
the first time around. A separate set of 
instructions for each would have been 
more reasonable. 

Both Illustrator and Streamline person¬ 
alize the installation by asking for your 
name and organization. Incredibly, Illus¬ 
trator modifies the distribution diskette 
with this information. Streamline doesn’t 
do this, but it won’t accept a long organi¬ 
zation name — the name of my company 
is too long for Streamline but fine for Il¬ 
lustrator. 

Now for the features. Figures 5 and 6 
give a good idea of what you can create 
with Illustrator and Streamline and why I 
like them so much. There’s more to these 
products than I could describe if I used 
the entire column, so I’ll just describe 
how I created the figures. 

For Figure 5,1 simulated working with 
a scanned file by taking a TIFF file of a 
left eye (provided with Streamline) and 
converting it to a Postscript format 
(called AI by Adobe). Once I created the 
AI file, I read it into Illustrator, copied it 
to the clipboard, and pasted it into a doc¬ 
ument file. Clicking on the reflection 
tool brought up a dialog box that let me 
copy a reflection of the image around the 
vertical axis. (The toolbox look is typical 
of paint and drawing programs.) 

When converting a file with Stream¬ 
line, you have several options at your 
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disposal. Three basic methods are the 
outline method, the centerline method, 
and a combination of the two. The out¬ 
line method traces an outline of each ele¬ 
ment in the image, filling each outline 
with either black or white. Adobe recom¬ 
mends this method for images with in¬ 
consistent line weights and filled areas, 
such as graphic designs and nontechnical 
line-art images. An image of a zebra is a 
good example. 

The centerline method locates the cen¬ 
ter of each line and creates a stroked 
path. Adobe recommends this method for 
converting technical images that include 
consistent line weights and no filled ar¬ 
eas, such as mechanical drawings and 
technical illustrations. The staircase in 
Figure 6 was converted this way from a 
TIFF file provide with Streamline. 

I used the combination method to con¬ 
vert the TIFF file for the eye. This meth¬ 
od is for images that contain both consis¬ 
tent line weights and filled areas. 

Each method has options to enhance 
the conversion process. For example, 
both the outline and combination meth¬ 
ods let you set a noise level to eliminate 
stray pixels that result from scanning a 
poor-quality image. Streamline ignores 
any pixel areas smaller than the noise 
level. Also, you can use the centerline 
and combination methods to make all 
lines a uniform width of 0-12 points. If 
the line widths in the image are not uni¬ 
form, you can let Streamline try to match 
the line widths in the bitmapped image. 

Once you have converted a bitmapped 
image for Illustrator, you can modify it 
in many ways. I already described reflec¬ 
tion. It’s also easy to scale images. The 
eye in Figure 6 was scaled down from its 
original size (as shown in Figure 5). The 
staircase was also scaled down. As with 
most Illustrator capabilities, there’s a 
quick way and a precise way to do 
things. I’ll explain the scaling tool in de¬ 
tail so you’ll see how easy the tools are 

After selecting the scaling tool, you 
can quickly scale an image by clicking 
on a point to the left and below the im¬ 
age (the selection point), moving the 
mouse to a point above and to the right 
of the image, and then dragging the 
mouse away to increase the size, or drag¬ 
ging it towards the image to decrease the 
size. Holding down the Shift key results 
in uniform scaling; holding down the Alt 
key results in a scaled copy of the image. 

For precise scaling, press the Alt key 
at the selection point. This brings up a 
dialog box that lets you specify the exact 
scaling. If you want nonuniform scaling, 
you can specify the horizontal and verti¬ 
cal scaling. 

Excluding the eye, staircase, and text, 
the other images in Figure 6 are supplied 



Figure 5. A TIFF file, duplicated and “reflected” in Adobe Illustrator. 



Figure 6. Streamline and Illustrator provide a variety of images. 
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with Illustrator as part of its package of 
symbols, borders, and letterforms. This 
package contains about 400 images that 
are ready to use. The images are grouped 
in documents, each containing 4-12 im¬ 
ages. To use one of the images, just open 
the image document, select the image, 
copy it to the clipboard, and paste it into 
your document. 

The frame around the eye is just one of 
several frames provided. I used it at its 
original size, scaled down the eye, and 
moved the eye into the center of the 
frame. The pointing hand is at its origi¬ 
nal size, but the “no” symbol was scaled 
to increase its size and then moved over 
the hand. If I had moved the hand over 
the circle instead, it would have hidden 
the crossbar (although I could have used 
Illustrator’s “Paste in Back” command to 
move the hand behind the symbol). 

The “no” symbol and the frame can be 
created easily in Illustrator. To make the 
frame, for example, you first select the 
rectangle tool. After positioning the 
mouse cursor at the upper right-hand cor¬ 
ner and holding down the Shift key to 
constrain the rectangles to squares, you 
drag the rectangle to the size you want. 
(Holding down the Alt key would let you 
draw rectangles from the center out.) 
Then, scaling with the copy option, you 
create the thin, inner square. You can use 


Head of the class 


Every now and then a product appears 
that is clearly far ahead of the competi¬ 
tion. Quattro Pro from Borland is the lat¬ 
est entry in the spreadsheet arena and 
easily one of the best software products 
of any type I have seen. Quattro Pro is 
much more than an upgrade to Quattro. 
Although you can operate it with much 
the same look and feel of Quattro, the 
new version is so much better that it 
should be viewed as an entirely new 
product. 

Quattro Pro is supplied on both 3.5- 
and 5.25-inch diskettes — a welcome 
feature if you have only one drive type 
and you fail to specify the distribution 
disk size. The effort to install the system 
is minimal. You can either use the auto¬ 
matic installation program or copy the 
files directly to your hard disk, in which 
case Quattro Pro will enter the installa¬ 
tion program automatically the first 
time you try to run the main program. In 
either case, installation is easy and ex¬ 
tremely intuitive. The complete package 
requires about 3 Mbytes of hard disk 
space. 


the Transform Again command, Ctrl-D 
on the keyboard, to create the inner rect¬ 
angle. You can set the line widths with 
the Paint menu. 

As easy as it is to create this frame, 
it’s already provided to save you time. 
Other symbols, such as the hands, the 
scissors, and the border can also be cre¬ 
ated in Illustrator, but it takes much more 
effort and talent. Fortunately, Illustrator 
gives you these, too. 

The hand illustrates that you can cre¬ 
ate drop shadows with Illustrator. The 
staircase’s thought balloon consists of 
one of the provided graphics plus text 
that I added using the text tool. This tool 
offers the 35 scalable fonts provided by 
the Apple LaserWriter. I chose the point 
size for the “Twin Peaks?” text to fit in 
the graphic. 

The arrow with the “Laura Palmer” 
text was created in several steps. I first 
used the text tool to select the font, point 
size, and leading, and to type in the text. 
Then I used the arrow (one of the sup¬ 
plied graphics) and scaled it so that it 
would enclose the text. Then I used the 
shear tool to slant the arrow and text. 

I’m not very good at drawing, but I 
can use The Complete Scanner to scan an 
image and then either convert it with 
Streamline or use it as a template in Il¬ 
lustrator. As a template, I can combine 


If you later want to change any of the 
installation options, such as the printer 
type or the graphics card, you can do so 
directly through the menu system with¬ 
out having to reinstall the program. In 
fact, you can modify almost any feature 
of Quattro Pro in this way, including the 
system’s entire look and feel. 

Quattro Pro offers four separate dis¬ 
play modes, which are selectable from 
the Options menu. Three of the modes 
are text based: 80x25-line mode, 80x43- 
line EGA mode, and 80x50-line VGA 
mode. The fourth display mode is graph¬ 
ics. Although all of the text modes are 
satisfactory, the graphics mode really 
shines. All modes provide full mouse 
support. 

There are three distinct menu styles: 
the familiar Lotus 1-2-3 format, Quattro 
style (from the previous version), and a 
new style specific to Quattro Pro. The 
new menus are similar to the old version, 
so you won’t have to learn an entirely 
new configuration, but they are different 
enough to offer distinct advantages. If 
you are moving to Quattro Pro from a 


Illustrator’s drawing tools along with its 
autotrace tool to create my own images. 
To help you use templates, Illustrator lets 
you view just the artwork, just the tem¬ 
plate, or the artwork and the template to¬ 
gether. 

These examples provide just a glimpse 
of Illustrator’s power. If you need to in¬ 
clude graphics in your documents and 
you can’t draw, you need Adobe Illustra¬ 
tor and Streamline. If you can draw, you 
will be able to create great looking 
graphics easily. Adobe Systems is at 
1585 Charleston Road, Mountain View, 
CA 94039, phone (800) 344-8335. 
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Summary 

You have many choices if you want 
Postscript output from a Laserjet printer. 
For an actual Laserjet printer, the Pacific 
Page cartridge is the best choice, with 
the AP-TeX fonts a good second choice 
for TeX users. For the rest of you, I don’t 
recommend either of the software inter¬ 
preters. If you need one, there are others 
on the market. I hope they are better. 


system with 1-2-3 style menus, you will 
quickly get up to speed. 

You can specify either tiled or stacked 
windows, and you can zoom tiled win¬ 
dows to full-screen size and back again 
with a single hotkey. A maximum of 32 
windows are available. You can move 
between stacked windows by selecting 
the desired window from a menu list, or 
you can simply click on the corner of the 
window with the mouse. You can also use 
the mouse to move and size any window. 

Quattro Pro lets you save a series of 
open files as a single named workspace. 
When you later reload the workspace, the 
previous window configuration is fully 
restored. If you often deal with groups of 
related spreadsheets, you will find this 
feature indispensable. 

The program’s most powerful feature 
is its ability to link data from several 
spreadsheets, which can eliminate the 
need to enter data more than once or to 
explicitly manipulate data from many 
spreadsheets to create summary informa¬ 
tion. Quattro Pro implements links as 
formulas that relate to a cell or a block of 


COMPUTER 







data in any spreadsheet in your system. 
The link formula is automatically updat¬ 
ed when the data in a referenced spread¬ 
sheet changes if that spreadsheet is open. 
If the spreadsheet is not open, you can 
explicitly update link references by 
choosing the Update Refs option from 
the menu. Also, when you load spread¬ 
sheets containing links, the program asks 
you if it should update any references to 
unloaded spreadsheets. The program will 
then load only the required data, rather 
than the entire referenced spreadsheet. 

Quattro Pro offers outstanding graph¬ 
ics capabilities. You can choose any of 
10 basic graphic types from a pictorial 
display including line graphs, pie charts, 
bar graphs, area graphs, and x,y graphs. 

A fast-graph feature is also available, in 
which you mark a block of data in the 
spreadsheet and let the program automat¬ 
ically partition the data, create the re¬ 
quired labels and legends, and display 
the data in graphics form. Nine Bitstream 
Fontware typefaces are available for text 
in your graph: Swiss and Dutch in italic, 
bold, bold italic, and regular, and Courier 
in regular only. All the fonts can be 
scaled from 6 to 72 points. 

One of Quattro Pro’s easiest and most 
useful features is the graph annotator, 
which resembles many of the popular 
drawing packages and lets you put a vari¬ 
ety of images into your graph, such as 
boxes, ellipses, and arrows. You can use 
the feature to control fonts in your graph 
and the placement of associated text, and 
you can change colors and patterns by 
selecting from a fixed pallet. A set of 35 
Picture Pak clip art images is also includ¬ 
ed. I found that the annotator became an 
indispensable tool for creating sophisti¬ 
cated graphics in a very short period of 

Quattro Pro’s linking feature carries 
over into its graphing capabilities. The 
program lets you plot data from multiple 
spreadsheets in the same graph. In fact, 
none of the data in a graph need come 
from the active spreadsheet or from any 
loaded spreadsheet. This ability proves 
very useful when preparing summaries 
for quarterly and annual reports, obviat¬ 
ing the need for a separate spreadsheet 
with only the summary data. 

You can save any Quattro Pro graph as 
a named graph and recall it later. This 
lets you maintain a series of differently 
styled graphs representing related data. 
You can also prepare a slide show that 
presents a named graph for a fixed length 
of time before displaying the next named 
graph in the series or returning to your 
spreadsheet. 

Quattro Pro lets you insert a graph 
directly into a spreadsheet as long as 
you’re using the graphics display mode 
for the spreadsheet rather than one of the 


character modes. Once in the spread¬ 
sheet, the graph is automatically updated 
whenever any of its data changes. Al¬ 
though I liked this feature very much, I 
found that the graph’s relatively small 
size often lowered its resolution to the 
point where it was no longer useful. 

Printing spreadsheets can often be 
frustrating because of their awkward 
size. Quattro Pro helps alleviate this 
problem with a screen preview function 
that lets you see what your printed output 
will look like (except for minor font dif¬ 
ferences). The preview function provides 
both a ruler and three separate zoom lev¬ 
els. The ruler is most useful in determin¬ 
ing the exact layout of your spreadsheet 
on a printed page, while the zoom feature 
provides greater detail for small sections 
of the page. You can display the preview 
in either portrait or landscape mode. 

Quattro Pro easily imports spread¬ 
sheets created with either Quattro or Lo¬ 
tus 1-2-3 Version 2.01, and it can save 
them again in the same format. However, 
if you create any special graphics during 
your session, you must first save the 
spreadsheet in the new Quattro Pro for¬ 
mat to avoid losing the information. You 
can then save the file in the older format. 
I frequently pass data among Quattro and 
Lotus users, and I found no problem with 
compatibility. 

I have used Quattro Pro extensively as 
an accounting tool to track daily, month¬ 
ly, and annual receipts and expenditures 
for a small business. The program’s abil¬ 
ity to link data from several spreadsheets 
has eliminated much of the duplication 
and additional work required to create 
summary spreadsheets. Its outstanding 
graphics capabilities, including the 
graphics link feature, have greatly helped 
my ability to spot trends and forecast 
performance. 

Quattro Pro contains many features I 
have not mentioned, including context- 
sensitive help, a file manager, an inter¬ 
face to Paradox and dBase data files, out¬ 
standing macro facilities, and 
mathematical features such as regression 
analysis and linear programming. If you 
are looking for a spreadsheet package, I 
strongly recommend that you consider 
Quattro Pro. 

Quattro Pro 1.0 requires 512 Kbytes of 
RAM, a hard disk, and DOS 2.0 or high¬ 
er. If you want to use its full graphics ca¬ 
pabilities, you will also need an EGA, 
VGA, CGA, AT&T, or Hercules graph¬ 
ics card or an IBM 8514 or 3270 PC. The 
retail price is $495. Quattro Pro is avail¬ 
able from Borland International, 1800 
Green Hills Road, P.O. Box 660001, 
Scotts Valley, CA 95066-0001, phone 
(408) 438-5300. —Daniel McAuliffe 
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Review notes 

Microspell. If you do a lot of writ¬ 
ing like I do, you need a spelling 
checker that is easy to use and doesn’t 
get in the way. I’ve found one I think 
you will like. 

Microspell, from Trigram Systems, 
is fast and full of features that make it 
a pleasure to use. It’s system require¬ 
ments are so modest that it will run on 
any IBM PC or clone with at least one 
floppy and 128 Kbytes of RAM. 

I tried it on a 43,000-character La- 
TeX file. It quickly found the repeat¬ 
ed words “the the” and some mis¬ 
spellings. When I ran the corrected 
file through it, Microspell took just 
over five seconds to check the entire 
document. 

When Microspell finds a suspect 
word, it tells you what it thinks is 
wrong — for example, misspelling, 
irregular capitalization, or both. With 
a single keystroke you can tell Micro¬ 
spell to treat the word as correct for 
the rest of the document (or just for 
this instance). 

The Save command lets you save a 
suspect word on an exception list and 
ignore it for the rest of the file. When 
you’re done checking your document, 
you can add the exception list to an 
auxiliary dictionary, save it, or both. 

Suspect words can be replaced by 
typing a replacement of up to 48 char¬ 
acters. Microspell then resumes 
checking from the start of the replace¬ 
ment to ensure that you didn’t make a 
spelling error in the new text. 

You can also replace suspect words 
hy choosing a new word from a pop¬ 
up window containing a numbered list 
of up to nine replacements. 

If you need to make major correc¬ 
tions around a suspect word. Micro¬ 
spell’s Edit command displays the 
portion of the file immediately sur¬ 
rounding the word. Standard cursor 
movement keys let you move around 
the file, and standard editing keys let 
you delete characters and enter new 

The lookup command lets you 
search Microspell’s dictionary using 
* and ? wildcards. For example, 
“d*d*d” matches all words beginning 
with the letter “d” and containing at 
least two more “d’s.” What’s espe¬ 
cially nice is that you can also invoke 
Microspell from the DOS command 
line to look up individual words with¬ 
out performing a full spelling check. 
For example, “ms -w d*d*d” looks up 
words matching the pattern just de¬ 
scribed. 
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You can maintain Microspell’s main 
dictionary by permanently adding and 
deleting words. There’s also an auxil¬ 
iary dictionary containing local addi¬ 
tions to the dictionary that is loaded 
whenever Microspell is invoked. 

The only problem I found with 
Microspell is that you can’t have a lo¬ 
cal dictionary. Instead, you get an aux¬ 
iliary dictionary for each file, which 
can be annoying if you are nesting files 
using an include-file capability. Tri¬ 
gram says this will probably be modi¬ 
fied in the next release, which should 
be out by the time you read this. 

You can also configure Microspell 
for your text processor. For example, 
you can have it ignore words that be¬ 
gin with command triggers. TeX users 
will find this especially useful. 

If you aren’t satisfied with your 
spelling checker, get Microspell. You 
won’t be disappointed. The price is 
$69.95. Trigram Systems is at 5840 
Northumberland St., Pittsburgh, PA 
15217, phone (412) 422-8976. —F. 
Pappas 


VP-Expert/SQL. This software 
from Gupta Technologies combines a 
rule-based expert system and the 
Structured Query Language for rela¬ 
tional databases to help you create ex¬ 
pert-system front ends for databases. 

Its potential applications span a wide 
variety of domains. The advantage of 
marrying VP-Expert to SQL is the lat¬ 
ter’s widespread use as a data-manipu- 
lation language for relational database 
systems and the potential to develop 
personal-computer expert systems 
that can access databases on larger 
systems. 

The expert system uses knowledge¬ 
base rules to analyze data in a relation¬ 
al database. The rules have the general 
form “if C then B1 else B2,” where 
condition C involves the fields of a ta¬ 
ble’s current record and B1 and B2 are 
blocks of statements that affect vari¬ 
ables defined in the knowledge base. 
VP-Expert/SQL’s inference engine al¬ 
lows for automatic rule generation 
from induction tables, which contain in 
each row the value of the premises and 


of the conclusion (plus a confidence 
factor). Induction tables can be created 
either from SQL or directly via an edi¬ 
tor that comes with the product. 

VP-Expert/SQL automatically trans¬ 
lates between its own language and 
SQL, eliminating the need to know 
SQL. The typical interrogation of data¬ 
base tables for expert system use does 
not require SQL’s full power, so using 
the translation can be an advantage 
over using SQL directly. The product 
also allows dircet access to SQL. 

VP-Expert/SQL’s organization is 
helpful, and its nice graphic presenta¬ 
tion of the menus lets the user consult, 
inspect, and modify the knowledge 
bases. There are minor discrepancies 
between the manuals and the real prod¬ 
uct, and not all of them are mentioned 
in the “read me” files, but they should 
not deter a seasoned programmer. The 
suggested retail price of $695 makes 
VP-Expert/SQL a good buy. Gupta 
Technologies is at 1040 Marsh Road, 
Suite 210, Menlo Park, CA 94025. — 
Dan Simovici 


1990 Winter Simulation Conference 

December 9-12, The Fairmont Hotel, New Orleans 


Who Should Attend? The 1990 Winter Simulation 
Conference is an important event for everyone with 
interest in simulation. Practitioners applying simula¬ 
tion to manufacturing or service system analysis, re¬ 
searchers dealing with issues such as simulation lan¬ 
guage improvements and output analysis, and 
educators keeping up with simulation state-of-the- 
art will all find papers and presentations of interest. 

Types of Presentations: The 1990 WSC focuses on 
discrete-event simulation and will feature basic tuto¬ 
rials, papers on applications and methodology, panel 
discussions, and state-of-the-art reviews. The 
keynote speaker is Philip Kiviat, originator of the 
simulation language GASP and leader in develop¬ 
ment of the language SIMSCRIPTII. 

Software Tutorials: The 1990 WSC will feature an ex¬ 
tensive schedule of tutorials on simulation software 
products presented by leading researchers and soft¬ 
ware developers. There are tutorials for all audi¬ 
ences: assuming no previous background in simula¬ 
tion, users who want to increase their knowledge of 
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simulation, and researchers who want to learn about 
advanced and emerging topics. 

Exhibit Area: There will be an extensive exhibit area 
for demonstrations of the latest advances in simula¬ 
tion software by software suppliers, with opportuni¬ 
ties for you to speak to the software developers per¬ 
sonally . 

General Chair for WSC '90 is Dr. Randall P. Sadowski 
of Systems Modeling Corporation and Program 
Chair is Dr. Richard E. Nance of Virginia Tech. 

For a copy of the preliminary program and/or for 
registration information contact: 

1990 WSC Registration Headquarters 
c/o EPIC Management, Inc. 

8720 Red Oak Blvd. 

Suite 224 

Charlotte, NC 28217 

1-800-447-6949 (available 9-5 Eastern time) 















TRI-Ada 


Soaring into the Nineties 


The world’s largest conference and exposition 
devoted exclusively to Ada development and trends 



• Policy makers 

• Engineering managers 

• Research scientists 

• Marketing & Sales executives 

• MIS programmers, engineers 

and developers 

• Automation experts 

• Educators 

• Technicians... 


“TRI-Ada... is one of the 
most important conferences 
in this nation." 

Congressman John Murtha, 
Chair, House Subcommittee 
on Defense Appropriations. 


.. .Whether you’re an Ada novice 
or a seasoned pro, TRI-Ada '90 is 
for you. Expand your knowledge 
and expertise through: 

• Wide-ranging technical and 
management sessions, tutor¬ 
ials and panel discussions 
led by top experts from 
industry, government and 
academia. 

• A dynamic three-day expo¬ 
sition of the latest Ada tools 
and applications.. .Visit more 
than 100 exhibitors includ¬ 
ing Boeing, Contel, Harris 
Computer, Hewlett-Packard, 
IBM, McDonnell Douglas, 
Telesoft, Unisys, Westing- 
house... and many more 
industry leaders. 


• Exciting holiday entertain¬ 
ment and special events 
where you’ll meet and mix 
with your peers... 

For conference registration and 
exposition information, mail or fax 
the coupon to: 


TRI-Ada ’90 

Danieli & O’Keefe Associates, Inc. 
Conference Management 
75 Union Avenue 
Sudbury, MA 01776 
FAX: 508-443-4715 
Or call 1-800-848-5381 
(In MA: 508-443-3330) 


YES! D 

□ 

1 am interested in attending TRI-Ada ’90. 

Send me conference program and registration information. 

1 am interested in exhibiting. Send me exposition information. 

Name: 


Titlfi- 


Address: 

City, State, Zip: 

TeleDhone: ( 


) 
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INDUSTRY • ACADEMIA • GOVERNMENT 


December 3-7,1990 • Baltimore Convention Center • Baltimore, MD 

Sponsored by ACM/SIGAda and Baltimore SIGAda 




















NEW PRODUCTS 


Contact or send releases to Steve Wilcox, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail II, s.wilcox 


Hand-held scanner puts text directly into applications 


Caere Corp. says its Typist hand-held 
scanner can import text and numbers di¬ 
rectly into a user’s application at 500 
words per minute. 

The 300-dpi scanner was designed 
specifically for page recognition and in¬ 
cludes the company’s Anyfont optical 
character recognition system, which rec¬ 
ognizes text regardless of the font or 
number of columns, according to the 
company. (In multicolumn formats, the 
scanner recognizes only the center col¬ 
umn and throws away incomplete col¬ 
umns on either side.) Anyfont supports 
11 languages and reads nonstylized fonts 
from 6-72 points in either landscape or 
portrait orientation. 

Caere says the Typist offers a scanning 
speed of up to two inches per second and 
resets automatically to allow for either 
horizontal or vertical scanning. As a user 


scans text with the Typist, keyboard op¬ 
eration is interrupted, and data from the 
scanner enters the application via the 
keyboard buffer. 

The Typist can also scan graphic im¬ 
ages using image capture software sup¬ 
porting PCX, TIFF, and Piet output file 
formats. A dither pattern switch lets the 
user choose from four patterns when 
scanning photos or line art. 

The Macintosh version requires 4 
Mbytes of RAM and at least a Macintosh 
SE. It includes a SCSI interface box and 
costs $695. The 286 and 386 versions re¬ 
quire a PC compatible with an AT or Mi¬ 
cro Channel bus, 640 Kbytes of RAM, 2 
Mbytes of expanded or extended memo¬ 
ry, and a hard disk. They include an AT- 
or MCA-interface card and cost $595. 
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Fujitsu’s VP2000 series 
expands 

Fujitsu’s VP2400/40 and VP2200/40 
supercomputers feature four scalar pro¬ 
cessors and two vector processors, and 
offer maximum vector performance of 5 
Gflops and 2 Gflops, respectively. 

The systems are expected to be avail¬ 
able in September of 1991. Monthly rent¬ 
al fees are about ¥79,000,000 for the 
VP2200/40 and about ¥103,000,000 for 
the VP2400/40. 

Fujitsu has also announced its UXP/M 
operating system for the VP2000 series 
and M series (M-780/770/760 model 
groups). The operating system is based 
on Unix System V Release 4. Fujitsu ex¬ 
pects to deliver UXP/M in April 1991, 
with a monthly rental fee for the basic 
software starting at ¥210,000 yen. 
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IBM System/390 encompasses new processors, architectures, operating systems 


In a massive product announcement, 
IBM has rolled out its System/390, in¬ 
cluding new operating systems, connec¬ 
tion architectures, and 18 new Enter¬ 
prise System/9000 mainframe 
processors. 

All ES/9000 processors support the 
new Enterprise Systems Connection 
(Escon) architecture, which uses fiber 
optic channels that transfer data at up to 
10 Mbytes/sec. Escon lets users place 
I/O equipment as far as 5.6 miles (9 
kilometers) from the processor, accord¬ 
ing to the company. 

ES/9000 models also support logical 
partitioning between multiple operating 
systems at the same time to allow simul¬ 
taneous use of production, development, 
maintenance, and test applications. 

The 18 ES/9000 processors range 
from the rack-mounted, uniprocessor 
Model 120 with processor storage of up 
to 256 Mbytes, a maximum of 12 Escon 
and parallel channels, and no vector fa¬ 
cilities, to the water-cooled, six-way 
multiprocessor Model 900 with up to 9 
Gbytes of processor storage, a maxi¬ 
mum of 256 Escon and parallel chan¬ 
nels, and up to six vector facilities. 

Fourteen of the new processors will 
support optional vector facilities, and 



An air-cooled, rack-mounted ES/9000 


some models allow overlapping of the 
scalar and vector execution elements and 
support multiple pipelines. 

The ES/9000 series uses IBM’s new 
Enterprise Systems Architecture/390. 
ESA/390 encompasses the VSE/ESA, 
VM/ESA, and MVS/ESA operating sys¬ 
tems, which can also run programs and 
applications based on the System/370 ar¬ 
chitecture. 

System/390 also includes integrated 
cryptography at central processor speeds 
and an external time-reference system 
that lets customers synchronize multiple 
processors and run them as one system. 

Basic prices for the air-cooled proces¬ 
sors range from about $70,500 to $3.12 
million, with some models available 
now. Basic prices for the water-cooled 
models range from $2.45 million to 
$22.8 million, with most models avail¬ 
able now. 

IBM is offering direct upgrades for 
owners of ES/3090 J Models 180, 200, 
280, 300, 400, 500 or 600, and E5/9370 
Models 50, 60, 80, or 90. Also, entry- 
level E8/3090 uniprocessors can be up¬ 
graded to one of five ES/3090-9000T 
transition models. 
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Intergraph offers low-end 
workstations, servers 

Intergraph has aimed its Series 2000 
color graphics workstations and servers 
at such markets as mechanical design, 
mapping, and electronic publishing. 
Prices begin at $15,900. 

Each workstation includes a 12.5- 
MIPS RISC processor, 160,000 2D vec¬ 
tors per second, and 100,000 3D vectors 
per second. The series includes such 
software as XNS, TCP/IP communica¬ 
tions, Looking Glass (a graphical user in¬ 
terface), and Intergraph’s implementa¬ 
tion of Unix System V, Release 3.1 with 
Berkeley extensions. 

The four workstation models are a 
desktop Interpro 2020 with a single 19- 
inch screen; the Interact 2020 with a sin¬ 
gle 19-inch screen, integral furniture, and 
a menu tablet, a desktop Interpro 2020 
with dual 19-inch screens, and the Inter¬ 
act 2020 with dual 19-inch screens, inte¬ 
gral furniture, and a digitizing table. 

The Interserve 2000 includes a 12.5- 
MIPS RISC processor, 16 Mbytes of 
memory (expandable to 64 Mytes), a 
200-Mbyte hard disk drive, a 1.44-Mbyte 
floppy disk drive, communications ports, 
and serial and parallel ports. 
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SCSI laser printer 
designed for graphics 
applications 

NCR’s new laser printer is targeted at 
graphics-intensive applications in the 
personal computer market. The SCSI 
interface of the 15-page/minute printer 
is designed to operate up to seven times 
faster than a standard parallel port and 
100 times faster than a RS-232 serial 
port, according to the company. 

The Model 6436-0301 allows shared- 
resource printing by accepting input 
from dual host systems. It also has a 
standard parallel interface, so that one 
host system can print on the SCSI port 
while another uses the parallel port. A 
mechanical output jogger separates jobs 
that print simultaneously. 

The printer has standard emulations 
for the HP Laserjet Series II, HP 
7475A, Diablo 630, Epson FX-86e/ 

286e, IBM Proprinter XL, and line 
printers. It also includes 35 resident 
scalable fonts. Standard memory is 2 
Mbytes and can be upgraded to 4 
Mbytes. The retail price is $7,995. 
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The Interact 2020 with dual 19-inch screens, integral furniture, and a digitizing 
table. 


Fujitsu mainframes embrace firm’s Mission/DC 


Five mainframes announced by Fujitsu 
are the first products in the company’s 
“Multienvironment Information Systems 
Solution by Domain” Concept (Mission/ 
DC), which divides mainframe functions 
into a database processing domain, an 
application processing domain, a com¬ 
munication processing domain, and a 
management processing domain. 

The M-1800 mainframes range from 
the two-processor Model 20 to the eight- 
processor Model 85. The latter supports 


main storage of up to 2,048 Mbytes, sys¬ 
tem storage of up to 8,096 Mbytes, and 
up to 256 channels. 

Monthly rental fees range from 
¥78,000,000 for the Model 20 to 
¥290,000,000 for the Model 85. The 
Models 20 and 30 are expected to be 
available by the end of April 1991, while 
the other models are due in the third 
quarter of 1991. 

Reader Service 40 


Ventura Publisher hits the Mac 


Ventura Software has announced the 
Macintosh version of its previously 
DOS-only Ventura Publisher. 

The new version offers such standard 
Ventura features as forward and back¬ 
ward automatic cross referencing, the 
ability to construct tables and scientific 
equations, long document capabilities 
(up to thousands of pages), letter kern¬ 
ing, and suppport for a wide variety of 
text and graphics files. 

Features sepcific to the Macintosh ver¬ 


sion include a spelling checker, undo/ 
redo, apply/cancel with dialog box chain¬ 
ing, movable dialog boxes, and on-line 
help menus. 

The Macintosh edition requires at least 
a Macintosh Plus with 2 Mbytes of 
RAM, System 6.0.2, Finder 6.0.2, and a 
hard disk drive. The retail price is $795, 
with shipments scheduled for the fourth 
quarter of 1990. 
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IBM adds low-cost models 
to AS/400 line 


IBM has added two low-cost com¬ 
puters to its AS/400 line and intro¬ 
duced a new AS/Entry model. 

The AS/Entry line is based on IBM’s 
System/36 architecture. The Model 
Y10 has 1-2 Mbytes of main memory 
and 160-640 Mbytes of storage. It is 
priced at $ 11,000, plus $ 1,195 for ver¬ 
sion 6 of the System Support Program 
operating system. 

The AS/400 Models C04 and C06 
have 8 Mbytes of main memory and 
640 Mbytes of storage. Users can in¬ 
crease the C04’s memory and storage 
capacity to 12 Mbytes and 960 Mbytes, 
respectively. Users can also upgrade 
both the C04 and AS/Entry Y10 to a 
C06 with up to 16 Mbytes of main 
memory and 1,280 Mbytes of storage. 

The C04 costs $14,500, plus $3,750 
for version 3 of the OS/400 operating 
system. The C06 is priced at $17,500, 
plus $6,350 for OS/400. 
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The IBM Application 
System/Entry Model Y10. 



Ada compiler designed for Wang VS systems 


Wang VS Ada, an Ada compiler for 
Wang VS computer systems, conforms 
to the ANSI standard and has been val¬ 
idated by the US Defense Dept.’s Ada 
Joint Program Office, according to 
Wang. 

Wang VS Ada gives users access to 
Wang Integrated Image Systems and 
VS operating system services. It is in¬ 


tegrated with the VS operating system 
environment and supports subroutine 
calls to other programming languages 
supported on the VS. 

Prices for Wang VS Ada range from 
$5,000 for low-end systems to $60,000. 
The product is available immediately. 
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Wireless LAN achieves 2-Mbit transmission rate 


NCR’s Wave LAN is a wireless local 
area network that transmits data at 2 
Mbits per second, according to the 
company. The Wave LAN is a printed- 
circuit board that fits a PC AT expan¬ 
sion slot and connects to an omnidirec¬ 
tional antenna. 

NCR says a Wave LAN installation 
can include any number of PCs within 
a radius of 800 feet in an open office, 
with a working range from 250-1,000 
feet, depending on the office environ¬ 


ment. The company also claims that of¬ 
fice partitions or normal office con¬ 
struction (except thick concrete or met¬ 
al) will not block transmission. 

The product is compatible with No¬ 
vell Netware and has a suggested price 
of $1,390 for the network interface 
card, Novell drivers, and antenna. An 
optional Data Encryption Standard se¬ 
curity feature is $90. 
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Hand-held scanner handles 
256 gray levels 

Logitech has announced the Scanman 
Model 256, a hand-held scanner featur¬ 
ing several proprietary analog and digi¬ 
tal chips created to enhance hardware- 
to-software communication and more 
closely simulate how the human eye per¬ 
ceives the spectrum of gray scales. 

The scanner includes Ansel image-ed¬ 
iting software, designed to run under 
Microsoft Windows 3.0 and featuring 
256 gray-level image manipulation. 
Ansel is compatible with such file for¬ 
mats as compressed and uncompressed 
TIFF, TIFF CCITT, BMP, PCX, and 
EPS. It accepts a wide variety of input, 
from simple line art to full 8-bit 256- 
gray-level information. 

Ansel is designed to overcome some 
of Windows’ limitations, according to 
Logitech. For example, Ansel takes over 
control of the standard VGA color pal¬ 
ette from Windows to allow the display 
of the maximum number of gray levels. 

Ansel’s image-manipulation options 
include additional brightness, contrast, 
and gray-level adjustments. Users can 
resize, flip, rotate, and scale images, as 
well as smooth and sharpen textures and 
create negative and posterized images. 
The software also includes a “de-skew” 
command to realign documents that 
have been scanned at a angle. 

The scanner has a retail price of $499 
for the PC version ($599 for the Micro 
Channel version) and carries a lifetime 
hardware warranty. 
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LAN Manager 2.0 features 
new pricing scheme 

Microsoft’s has announced a new 
pricing arrangement to support version 
2.0 of its LAN Manager. LAN Manager 
2.0’s $995 price includes support for 
five users. User packs to support addi¬ 
tional groups of up to 10 users are $995 
each. An unlimited number of users 
can be supported for $5,495. 

According to the company, Version 
2.0 integrates with Microsoft Windows 
3.0, supports 386 and 486 servers, and 
automatically configures to the server 
type, including installation of a 32-bit 
network-optimized I/O subsystem. 

Reader Service 46 
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Company, Model, Function 

Comments R.S. No. 

Accutek Microcircuit 
Accutek Forty Plus 
High-density memory 
modules 

One-Mword x 8-bit CMOS DRAM modules for 40 MHz computers come in 1M and 4M versions, 120 

operate in read-write and read-write-modify modes for high-speed applications, and provide data- 
in, data-out, and write-enable lines to separate pins on separate buses. JEDEC 64-pin socket with 50- 
mil pin-to-pin spacing; 3.85" wide x 0.90" high. Cost: from $89. 

Analog Devices 

AD9014 

ADC 

ECL-compatible 14-bit ADC is factory tested at 10 megasamples/s with analog input frequencies of 121 
540 kHz and 2.3 MHz. Minimum spurious-free dynamic range is 90 dB, decreasing to 86 dB with in¬ 
put frequencies up to 4.3 MHz. Features minimum 75-dB signal-to-noise ratio and 90-dBc two-tone 
intermodulation distortion. Cost (100s): from $2,800. 

Analog Devices 
ADV7141,46,48 

Video RAM-D AC IC 

Pin-compatible upgrade for RAM-DAC IC on standard VGA systems implements Edsun’s Continu- 122 
ous Edge Graphics algorithm. Eliminates aliasing, provides realistic colors and subtle shadings, and 
displays text with laser-printer quality. Available in 44-pin PLCC 35-, 50-, and 66-MHz clock ver¬ 
sions and 28-pin plastic DIP. Cost (1,000s): $30-$50. 

Gould AMI 

S63 Series 

Military CMOS ROMs 

High-speed CMOS ROMs, including versions with 16-Kbit to 4-Mbit capacity, comply with Mil- 123 

Std-883C. The memories provide access times up to 100 ns and require a single +5 V power supply. 

The 4-Mbit ROM will be available in 512K x 8 and 256K x 16 configurations. Packages include 24- 
and 28-pin ceramic DIP and 32-pin CLCC. Cost (1,000s): $30-$ 105. 

Integrated Device 
Technology 

IDT 10494,100494, 
101494 

ECL SRAMs 

64K static RAMs use IDT’s 0.6 (Leff) micron BiCEMOS II process, which typically limits power 124 

consumption to 700 mW. Suited for implementing caches in ECL RISC systems, the devices are or¬ 
ganized as 16K x 4 bits with separate data inputs and outputs and are available with access times of 7, 

8,10, and 15 ns. Cost (100s) of 7 ns DIP version: $125. 

Integrated Device 
Technology 

IDT7RS355 
Floating-point library 

Floating-point library for R3000 RISC systems eliminates the need for an FPA chip, thus saving 125 

space on the board and allowing the development of applications that need single- and double-preci¬ 
sion floating-point capabilities but not the high performance of the coprocessor. Cost: $ 1,295. 

Intermetrics 

C cross compilers and 
debuggers 

Whitesmiths’ optimizing C cross compilers and CXDB C source-level cross debuggers for the Zilog 126 
Z80, Motorola 6809, Hitachi 64180 microcontrollers are preintegrated and provide a C development 
environment for embedded systems designers. Cost: compiler packages hosted on IBM PC, from 
$ 1,800; CXDB on IBM PC, $1,500. 

Motorola 

68HC1 IK Series 

8-bit microcontrollers 

T wo additions to Motorola’s 8-bit 68HC11 microcontroller family double the bus speed of the origi- 127 
nal family members. The K4 and 711K4 feature 768 bytes of RAM, 640 bytes of EEPROM, 62 I/O 
lines, a 16-bit timer, four 8-bit pulse-width modulators, 8-channel 8-bit A/D, and enhanced serial pe¬ 
ripheral and communication interfaces. No price given. 

RO Associates 
R048-D512 

DC-DC converter 

Dual-output DC-DC converter produces 5 V at 10A and 12 V at 8 A with a total maximum power of 128 

125 watts. Each output can be either a plus or minus 5 V or 12V; input range is 36-66 VDC with input 
overvoltage protection up to 100V. Module requires no heat sink or fan and complies with Mil 810D, 

UL, CSA, and IEC requirements. Cost (singles): $325. 

SP9462 

Data acquisition system 

Multichannel DAS in a 68-pin grid array features an 8-differential or 16-single-ended input multi- 129 

plexer, programmable gain instrumentation amplifier and sample-and-hold, and a 12-bit A/D con¬ 
verter. All timing, control, and voltage references are internal to the package, making the DAS a 
complete subsystem. Cost (100s): $ 100. 

Square D 

Micro-1 

Microcontroller 

Controller’s internal logic equals 160 relays and holds 600 steps of EEPROM memory. Controller 130 

has eight inputs and six outputs (expandable to 16 and 12), 80 timers, and 45 counters. Programming 
is via a small, plug-in program loader. Up to 32 controllers can be linked to a PC to monitor remote 
control panels and machines. Cost: $200. 

Xicor 

X24C02 

EEPROM 

CMOS 2-Kbit serial EEPROM is internally organized as one 256 X 8 page. It features a serial inter- 131 

face and software protocol that allows operation on a single two-wire bus. It is available in commer¬ 
cial and industrial temperature ranges and in 8-pin plastic DIP and plastic SOIC. Cost (100s): From 
$ 1.45 to $2.21, depending on temperature ranges and packaging. 
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Company, Model, Function 

Comments R.S. No. 

Ariel 

Quintprocessor 

Next DSP board 

This digital signal processing board for the Nextbus features five Motorola 27-MHz DSP56001 135 

DSPs, four as slave processors and one as an I/O processor that manages DRAM memory, SCSI 
mass storage, and interprocessor communication. The board is compatible with Ariel ’ s BUG-56, a 
symbolic debugger bundled with the Next computer. Cost: $6,995. 

Arcom 

VFDSC 

SCSI/disk controller 

A VMEbus board with a SCSI controller port for up to eight devices and an independent floppy disk 136 
port for up to four drives. Compatible with STEbus OS-9 driver software. LEDs display the status of 
the SCSI lines. The disk port can be polled or interrupt driven. Cost: £485. 

Borland 

Paradox 3.5/ 

Paradox SQL Link 

The new version of this relational database management system works with Paradox SQL Link to 137 

give users access to remote SQL data. Paradox includes new memory management technology, and 

Paradox SQL Link provides automatic configuration and transparent connection to SQL servers. 

Cost: Paradox 3.5, $795; Paradox SQL Link, $495; Paradox Multipack (five users) $995. 

CMS Enhancements 

PS/1 memory modules 

Two single-slot memory modules that provide up to 512 Kbytes or 2 Mbytes of expanded memory 138 

for the IBM PS/1 computer. Cost: 512 Kbytes, $ 169; 2 Mbytes, $595. 

Corollary 

8X2 board 

Multiport system 

A multiport subsystem providing RS-232 serial connections for 8- and 16-user PC AT 386- and 486- 139 
compatible systems. One board connected to two 8-port 8/tc+ terminal concentrators supports up to 

16 users; four boards support as many as 64 users. Each 8-port concentrator can be up to 1,000 feet 
from the host computer Cost: $995 for a basic kit, including an 8X2 board, an 8/tc+ terminal concen¬ 
trator, RS-422 host cable, RS-232 cable, documentation, and drivers 

Data Translation 

DT2812 

I/O board 

The DT2812 DMA analog I/O board and DT2812-A digital I/O board fit the long or short slots of PC 140 
XT and AT machines. Designed for the OEM market, the boards include counter/timers and soft¬ 
ware (MS-DOS device driver, toolkit subroutine library, and DT/Gallery). Cost: DT2812, $629; 
DT2812-A,$695. 

Dynatech 

386 SBC/486 SBC 
Single-board computers 

Two semicustom, single-board VMEbus computers based on the 80386 and 80486. Available with 141 

4,8, or 16 Mbytes of RAM and 32 Kbytes of cache memory. They can run DOS or Unix at 25 MHz or 

33 MHz,'and they include two RS-232 and six RS-422 serial ports, one parallel port, floppy disk in¬ 
terface, hard disk interface, keyboard interface, clock, and VGA graphics. Cost: From $7,500 for the 
386SBC. 

Grid Systems 

Gridcase 1550sx 

Laptop computer 

The 12-pound battery-powered Gridcase 1550sx features a built-in pointing device, 20-MHz 386SX 142 
processor, 60-Mbyte hard drive, 640X480 VGA backlit LCD screen, 2 Mbytes of RAM. Battery life 
is up to three hours, and it recharges in about two hours. Cost: $6,295; with optional 120-Mbyte hard 
drive, $6,995. 

Hewlett-Packard 

Deskjet 500 

Printer 

A 300-dpi, plain-paper printer compatible with Windows 3.0 (An enhanced HP driver that allows 143 

scaling fonts under Windows 3.0 is scheduled to ship later this year). Prints up to three pages of text 
or two pages of graphics per minute. Cost: $729. HP Deskjet PLUS and Deskjet owners can upgrade 
for$175 and $225, respectively. 

Pacific Data Products 
Pacific T Memory 

Printer memory board 

An memory board allowing users to expand the standard 512-Kbyte memory of TEC engine (Epson, 144 
Toshiba, AT&T, MCR, Mannesmann Tally, and Packard Bell) laser printers. The board can be up¬ 
graded from 2 to 4 Mbytes by adding memory chips. Cost: 2 Mbytes, $399; 4 Mbytes, $699. 

Piiceon 

4-Mbyte board 
forIBM80 A-21 

A 4-Mbyte memory board that plugs into the motherboard of the IBM 80 A-21 (a 3 86-based upgrade 145 
of the PS/2 80 that comes with 4 Mbytes standard). Cost: $ 1,895. 

3Com 

3 Server/600 

486-based server 

A server based on a 33-MHz 486 chip, otherwise identical to 3Com’s 386-based 3Server/500 with 146 

the 486/33 Option installed. The 486/33 Option is also available separately for $6,895. The price for 
the 3Server/600’s basic configuration is $24,250. 


COMPUTER 








Data Compression Conference 

(Sponsored by the IEEE Computer Society TCC in Cooperation with NASA/CESDIS) 

Snowbird, Utah 
April 8 - 10, 1991 


Program Committee: 
A. Blumer, Tufts U. 

R. Capocelli, U. Rome 
J. Cleary, U. Calgary 
P. Elias, MIT 

I. Daubechies, Bell Labs 
R. Gray, Stanford U. 

D. Hirschberg, UC Irvine 
A. Lempel, Technion 
V. Miller, IBM 

J. Reif, Duke U. 

D. Sheinwald, IBM 
J. Storer, Brandeis U. 

J. Tilton, NASA 
J. Vitter, Brown U. 

A. Wyner, Bell Labs 
J. Ziv, Technion 


Co-General Chairs: 

J. Reif, Duke U. 

J. Storer, Brandeis U. 


Publicity Chair: 

R. Miller, NASA/CESDIS 


Registration Chair: 
M. Cohn, Brandeis U. 


THEME: Data compression has become an essential component of high 
speed communications and mass storage. This conference will provide an 
international forum for current work on data compression and related areas. 
Topics of interest include but are not limited to: Coding theory, quantiza¬ 
tion theory, parallel algorithms and compression hardware, algorithms for 
specific types of data (including text, images, video, speech, maps, instru¬ 
ment data, graphics, animation, and bit-maps), transform methods, wavelet 
and fractal techniques, string searching and manipulation, closest-match re¬ 
trieval, theory of minimal length encoding and applications to learning, sys¬ 
tem issues (including error control, data security, and indexing), medical 
imagery, scientific and space data archives, data compression standards. 
SUBMISSION: Authors are requested to submit 3 copies of an extended 
abstract of at most 10 pages by December 14, 1990 to: 

Prof. Martin Cohn 
Computer Science Dept. 

Brandeis University 
Waltham, MA 02254 

(fax: 617-736-2741, email: marty@cs.brandeis.edu) 

NOTIFICATION: Authors will be notified of acceptance or rejection by a 
letter mailed on 1/15/91. A final draft is due 2/15/91. Students presenting 
papers are eligible for financial support to attend the conference. 
ADVANCE REGISTRATION: Registration includes reception, ban¬ 
quet, coffee breaks, and proceedings. For registrations received before 3/1/91, 
the fee is $295.00 for IEEE or affiliate members or $370.00 for non-members; 
there is an additional $100 late fee for registrations after 3/1/91. 

HOTEL: Space is limited; rooms may NOT be available after 3/1/91. 
Room rates are $42 per person for a double room and $84 for a single room. 
Call the Cliff Lodge, Snowbird, UT 84092, 800-453-3000 or 801-742-2222. 
TRANSPORTATION: The hotel may be reached by limousine or public 
bus from the Salt Lake City airport. 


REGISTRATION FORM 

NAME:_ 

AFFILIATION:_ 

ADDRESS:_ 


PHONE:_ EMAIL:_ 

@ IEEE member □ □ AMOUNT ENCLOSED: 


MAIL TO: 

DCC '91 

Att. Myrna Fox 
Computer Science Dept. 
Brandeis University 
Waltham, MA 02254 
















CALL FOR PAPERS 


Conf. on Advanced Research in VLSI: Mar. 
25-27, 1991, Santa Cruz, Calif. Submit five 
copies of draft paper by Oct. 15, 1990, to Car¬ 
lo H. Sequin, Univ. of California, CS Div., 
529B Evans Hall, Berkeley, CA 94720. 

ICDCS 91,11th Int’l Conf. on Dis¬ 
tributed Computing Systems: May 20- 

24, 1991, Arlington, Texas. Submit five cop¬ 
ies of abstract and paper by Oct. 23,1990, to 


Benjamin W. Wah, ICDCS 91, Coordinated 
Science Lab, MC228, Univ. of Illinois, 1101 
W. Springfield Ave., Urbana, IL 61801-3082, 
phone (217) 333-3516, fax (217) 244-1764, 
e-mail wah%aquinas@uxc.cso.uiuc.edu. 

Int’l J. of Computer Simulation plans a spe¬ 
cial issue in early 1991 on simulation of mul¬ 
tiple processor/distributed systems. Publisher: 
Ablex. Submit four copies of complete manu¬ 


script by Oct. 30,1990, to Kallol Bagchi, Inst, 
of Electronic Systems, Aalborg Univ., Fredrik 
Bajers Vej 7, DK-9220 Aalborg 0, Denmark, 
fax (45) 98-156-740, e-mail kkb@iesd.auc.dk. 

Second Int’l Conf. on Local Communica¬ 
tion Systems: June 26-28, 1991, Palma, 

Spain. Sponsor: Int’l Federation for Informa¬ 
tion Processing. Submit six copies of abstract/ 
paper by Oct. 31, 1990, to Ramon Puigjaner, 


Call for papers and referees for Computer 


Distributed Computing Systems has been selected as 
the theme for the August 1991 issue. Prospective authors 
are invited to submit tutorial, survey, descriptive, case-study, 
application-oriented, or pedagogic manuscripts. See the July 
1990 issue of Computer ( p. 120) for complete information. 

Abstracts are due by November 15, 1990, and the dead¬ 
line for full manuscripts is January 1,1991. Notification of 
decisions is set no later 
than March 15, 1991, and 
the final version of each 
manuscript is due no later 
than May 1, 1991. 

Submittals and questions 
should be directed to either 
of the guest editors, Muk- 
esh Singhal, Dept, of Com¬ 
puter and Information Sci¬ 
ence, Ohio State Universi¬ 
ty, Columbus, OH 43210, 
phone (614) 292-5839, 
e-mail singhal@cis.ohio- 
state.edu; or Thomas L. 

Casavant, Dept, of Electri¬ 
cal and Computer Eng., 

University of Iowa, Iowa 
City, IA 52242, phone (319) 

335-5953, e-mail tomc@ 
eng.uiowa.edu. 


• Experiences with implementing multimedia applications 

• Movies on a computer 

• Intelligent television technology 

• Interactivity and multimedia information systems 

• Combining video with 3D 

An abstract of each manuscript is due no later than De¬ 
cember 1, 1990, and eight copies of each full manuscript 
must be submitted by February 1, 1991. Notification of deci¬ 
sion is set May 1,1991, and the final version of each manu¬ 
script must be submitted 
by July 1,1991. 
Submissions and ques- 


Multimedia Information 
Systems will be the theme 
of the October 1991 issue. 

Manuscripts reporting sur¬ 
vey, original research, de¬ 
sign and development, and 

applications of multimedia technology are sought immediately 
in the following areas: 

• A tutorial/survey on multimedia information technology 

• Authoring techniques for multimedia systems 

• Storage and indexing of multimedia data 

• Communications of multimedia data 

• Dynamic data in multimedia systems 

• User interfaces for multimedia systems 

• Browsing in multimedia systems 

• Special workstations for multimedia applications 


For submittal to Computer, manuscripts must not have 
been previously published or currently submitted for publi¬ 
cation elsewhere. Each manuscript should be no more 
than 32 typewritten, double-spaced pages long, including 
all text, figures, and references. Each submittal should in¬ 
clude a cover page that contains the title of the article, the 
full name(s) and affiliation(s) of the author(s), complete 
postal and electronic address(es) of all the authors as well 
as their telephone and fax number(s), a 300-word abstract, 
and a list of keywords identifying the central issues of the 
manuscript’s contents. The final manuscript should be ap¬ 
proximately 8,000 words in length and contain no more 
than 12 references. 

If you are willing to review articles for any of these spe¬ 
cial issues, please send a note listing your research inter¬ 
ests to Bruce Shriver, editor-in-chief of Computer, or to 
one of the guest editors listed for the particular issue. 
Shriver may be reached at the University of Southwestern 
Louisiana, PO Drawer 42730, Lafayette, LA 70504-2730, 
phone (318) 231-5811, fax (318) 265-5472, e-mail 
b.shriver@compmaii.com or, on Internet, shriver@usi.edu. 


tions should be directed to 
A. Desai Narasimhalu, 

Inst, of Systems Science, 
National University of Sin¬ 
gapore, Heng Mui Keng 
Terrace, Singapore 0511, 
phone (65) 772-2002, fax 
(65) 778-2571, e-mail 
issad@nusvm; or Stavros 
Christodoulakis, Depart¬ 
ment of Computer Sci¬ 
ence, Davis Building, Uni¬ 
versity of Waterloo, Water¬ 
loo, Ont., Canada, phone 
(519) 888-4452 or (30) 
821-64846, fax (519) 885- 
1208 or (30) 821-53571, 
e-mail schristodoul@ 
waterloo.edu. 


Heterogeneous Dis¬ 
tributed Database Sys¬ 
tems is the theme planned 
for the December 1991 is¬ 
sue. See the August 1990 

issue of Computer ( p. 115) for complete information. 

Abstracts of the manuscripts are due no later than January 
1,1991 , and eight copies of the full manuscripts must be sub¬ 
mitted by April 1,1991. Notification of decisions is July 1, 
1991, and the final version of each manuscript is due Sep¬ 
tember 1, 1991. 

Submissions and questions should be directed to Sudha 
Ram, Department of Management Information Systems, Eller 
School of Management, University of Arizona, Tucson, AZ 
85721, phone (602) 621-2748, e-mail ram@mis.arizona.edu 
on Internet or ram@arizmis on Bitnet. 
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Univ. de les Illes Balears, Carretera de Vall- 
demossa, km. 7.6, 07071 Palma, Spain, phone 
34 (71) 207111, fax 34 (71) 758061 or 
200741, e-mail dmilan91@ps.uib.es. 


/£f^j Int’l Symp. on Software Reliability 
Eng.: May 17-18, 1991, Austin, Texas. 
Cosponsors: IEEE Computer Society Techni¬ 
cal Committee on Software Eng. and the Nat’l 
Aeronautics and Space Administration. Sub¬ 
mit five copies of full paper by Nov. 1,1990, 
to John C. Munson, Computer Science Div., 
Univ. of West Florida, Pensacola, FL 32514, 
phone (904) 474-2989, e-mail jmunson@ 
dcsnet.uwf.edu. 


Computer Graphics and Education 91: Apr. 
4-6, 1991, Barcelona, Spain. Sponsor: Int’l 
Federation for Information Processing. Submit 
six copies of extended abstract or draft paper 
by Nov. 1,1990, to Steve Cunningham, Com¬ 
puter Science Dept, California State Univ. at 
Stanislaus, Turlock, CA 95380, phone (209) 
667-3176, e-mail rsc@altair.csustan.edu; or 
Roger Hubbold, Computer Science Dept., 
Univ. of Manchester, Oxford Road, Manches¬ 
ter M13 9PL, UK, phone (44) 61-275-6158, 
e-mail hubbold@uk.ac.man.cs. 

Int’l J. Computer-Aided VLSI Design plans a 
special issue on VLSI implementations of arti¬ 
ficial neural networks. Publisher: Ablex. Sub¬ 
mit five copies of full papers by Nov. 1,1990, 
to Medhi Zargham, Computer Science Dept., 
Southern Illinois Univ., Carbondale, IL 
62901-45411, phone (618) 453-6048, e-mail 
ga3633@siucvmb on Bitnet. 

21st Int’l Symp. on Multiple-Valued Logic: 

May 26-29, 1991, Victoria, Canada. Submit 
five copies of manuscript and abstract by Nov. 
1,1990, to Wayne Current, Electrical Eng. 
and Computer Science Dept., Univ. of Cali¬ 
fornia at Davis, Davis, CA 95616, phone 
(916) 752-1839 or 0583 (for the Americas); 
Michel Israel, IIE-CNAM, 18, Allee Jean Ros¬ 
tand, BP 77, 91002 Evry Cedex, France, 
phone 33 (1) 60-77r97-40 (for Europe and Af¬ 
rica); or Okihiko Ishizuka, Electronic Eng. 
Dept., Miyazaki Univ., Miyazaki-Shi 889-21, 
Japan, phone (81) 985-58-2811 (for Asia and 
the Pacific). 

Eighth Int’l Conf. on Testing Computer 
Software: June 17-21, 1991, Washington, 

DC. Sponsor: Data Processing Management 
Assoc. Educational Foundation. Submit four 
copies of two-page abstract by Nov. 1, 1990, 
to Genevieve Houston-Ludlam, Frontier Tech¬ 
nologies, 190 Admiral Cochran Dr., Suite 180, 
Annapolis, MD 21401, phone (301) 266-8244, 
fax (301) 224-3840. 


North Am. Fuzzy Information Processing 
Soc. Workshop: May 15-17, 1991, Columbia, 
Mo. Submit one-page abstract by Nov. 1, 

1990, to Jim Keller, Electrical and Computer 
Eng., Univ. of Missouri — Columbia, Colum¬ 
bia, MO 65211, phone (314) 882-7339, fax 
(314) 882-0397. 

Fifth Int’l Conf. on Logic Programming: 

June 25-28, 1991, Paris. Cosponsors: Assoc, 
of Logic Programming et al. Submit six copies 
of paper by Nov. 3, 1990, to Koichi Furuka- 
wa, ICOT, Mita Kokusai Bldg., 21 F 4, 28 


Mita 1, Chome, Minato-ku, Tokyo, Japan 108, 
e-mail furukawa@icot.or.jp. 

DAC 91,1991 IEEE/ACM Design Au¬ 
tomation Conference: June 16-21, 

1991, San Francisco. Submit eight copies of 
paper and 60-word abstract by Nov. 7,1990, 
to Alfred E. Dunlop, c/o MP Associates, 7490 
Clubhouse Rd., Suite 102, Boulder, CO 
80301, phone (303) 530-4333.' 


(313) 936-1563, e-mail durfee @caen.engin. 
umich.edu. 

Third Symp. on Integrated Kerroelectrics: 

Apr. 3-5, 1991, Colorado Springs, Colo. Sub¬ 
mit abstract by Nov. 15,1990, to Conf. Secre¬ 
tary, Microelectronics Research Lab, Univ. of 
Colorado at Colorado Springs, PO Box 7150, 
Colorado Springs, CO 80933-7150, phone 
(719) 593-3488, fax (719) 594-4257. 


CICC 91, IEEE Custom Integrated Circuits 
Conf.: May 12-15, 1991, San Diego, Calif. 
Submit summary and abstract by Nov. 8, 

1990, to Roberta Kasper, CICC 91, 1597 
Ridge Rd. W, Suite 101C, Rochester, NY 
14615, phone (716) 865-7164. 


CVPR 91, IEEE Computer Soc. Conf. 
()n Computer Vision and Pattern Rec¬ 
ognition: June 3-7, 1991, Lahaina, Maui, Ha¬ 
waii. Submit four copies of complete paper by 
Nov. 12, 1990, to Gerard Medioni, Inst, for 
Robotics and Intelligent Systems, PHE 204, 
me 0273, Univ. of Southern California, Los 
Angeles, CA 90089-0273, e-mail medioni@ 
dworkin.usc.edu. 


SAC 91, 1991 Symp. on Applied Com 
puting: Apr. 3-5, 1991, Kansas City, 
Mo. Sponsor: Univ. of Missouri — Kansas 
City. Submit five copies of paper by Nov. 13, 
1990, to Vijay Kumar, SAC 91, Computer 
Science Telecommunications Program, Univ. 
of Missouri — Kansas City, 5100 Rockhill 
Rd., Kansas City, MO 64110-2499. 

ICCI 91, Int’l Conf. on Computing and In¬ 
formation: May 27-29, 1991, Ottawa, Cana¬ 
da. Sponsors: Carleton Univ, Ottawa; Natural 
Sciences and Eng. Research Council of Cana¬ 
da. Submit six copies of paper by Nov. 14, 
1990, to ICCI 91, School of Computer Sci¬ 
ence, Carleton Univ., Ottawa, Canada K1S 
5B6, fax (613) 788-4334, e-mail icci@scs. 
carleton.ca, 

® SCM 3, Third Int’l Workshop on 
Software Configuration Manage¬ 
ment: June 12-14, 1991, Trondheim, Norway. 
Cosponsors: ACM et al. Submit four copies of 
position paper and full paper by Nov. 15, 

1990, to Peter Feiler, Software Eng. Inst., Car¬ 
negie Mellon Univ., Pittsburgh, PA 15213-38 
90, phone (412) 268-7790, e-mail phf@ 
sei.cmu.edu. 

1^1 CAR 91, Fifth Int’l Symp. on Com 
^1^ puter-Assisted Radiology: July 3-6, 
1991, Berlin. Sponsor: Technical Univ. Ber¬ 
lin. Submit five copies of abstract by Nov. 15, 
1990, to Heinz U. Lemke, Inst, for Technical 
Computer Science, Sekr CG-FR3-3, Franklin- 
strasse 28-29, D-1000, Berlin 10, Germany, 
phone 49 (30) 314-73100; or Michael H. 
Rhodes, Toshiba America MRI, 280 Utah 
Ave., South San Francisco, CA 94080, phone 
(415) 875-2909. 


IEEE Trans, on Systems, Man, and Cyber¬ 
netics plans a special issue on distributed arti¬ 
ficial intelligence. Submit five copies of 
manuscript by Nov. 15, 1990, to Edmund H. 
Durfee, EECS Dept., Univ. of Michigan, 1101 
Beal Ave., Ann Arbor, Ml 48109-2110, phone 


Parle 91, Conf. on Parallel Architectures 
and Languages Europe: June 10-13, 1991, 
Eindhoven, The Netherlands. Cosponsors: 
Commission of European Communities et al. 
Submit paper by Nov. 15, 1990, to F. Stoots, 
Philips Research Labs, PO Box 80.000, 5600 
JA Eindhoven, The Netherlands, fax 31 (40) 
744-758, e-mail stoots@dooma.prl.philips. nl. 

KMET 91, Int’l Conf. on Knowledge Mod¬ 
eling and Expertise Transfer: Apr. 22-24, 
1991, Sophia Antipolis, France. Cosponsors: 
Assoc. Francaise pour la Cybemetique 
Economique et Technique et al. Submit four 
copies of paper by Nov. 15, 1990, to KMET 
91, Univ. de Nice, Sophia Antipolis, CNRS, 
13S-LISAN, Daniete Herin-Aime, bat. 4, rue 
A. Einstein, 06560, Valbonne, France, phone 
(33) 92-94-26-27, fax (33) 92-94-28-98, 
e-mail dh@cerisi.cerisi.fr. 

First Int’l Conf. on Artificial Intelligence in 
Design: June 25-27, 1991, Edinburgh, Scot¬ 
land. Submit full paper by Nov. 16, 1990, to 
John Gero, Architectural and Design Science 
Dept., Univ. of Sydney, NSW 2006, Australia, 
phone 61 (2) 692-2328, fax 61 (2) 692-3031, 
e-mail john@archsci.arch,su.oz or john% 
archsci.su.oz@uunet.uu.net. 

FTCS 21, 21st Int’l Symp. on Fault- 

Tolerant Computing: June 25-27, 

1991, Montreal. Sponsor: IEEE Computer 
Soc. Tech. Committee on Fault-Tolerant Com¬ 
puting. Submit six copies of paper by Nov. 19, 
1990, to Eduard Cerny, Univ. de Montreal, 
Departement d’l.R.O., PO Box 6128, Station 
A, Montreal, Que., Canada H3A 3J7, fax 
(514) 343-2155, e-mail cemy@iro. 
umontreal.ca. 


Symp. on Experiences with Distribut- 
ed and Multiprocessor Systems: Mar. 
21-22, 1991, Atlanta. Sponsor: Usenix Assoc. 
Submit 10 copies of full paper by Nov. 19, 
1990, to Gene Spafford, Software Eng. Re¬ 
search Center, Computer Sciences Dept., Pur¬ 
due Univ., West Lafayette, IN 47907-2004, 
phone (317) 494-7825, e-mail spaf@cs. 
purdue.edu. 

^3^, Arith 10, 10th Symp. on Computer 
Arithmetic: June 26-28, 1991, Greno¬ 
ble, France. Cosponsors: ACM et al. Submit 
four copies of complete paper by Nov. 19, 
1990, to David W. Matula, Computer Science 
and Eng. Dept., Southern Methodist Univ., 
Dallas TX 75275, phone (214) 692-3080, fax 
(214) 692-4138, e-mail matula@csvax.seas. 
smu.edu (for the Americas and the Pacific); or 
Peter Komerup, Math, and Computer Science 
Dept., Odense Univ., DK-5230 Odense, Den¬ 
mark, phone (45) 66-15-86-00, fax (45) 65- 
93-26-91, e-mail komerup@imada (for Eu¬ 
rope, Africa, and Asia). 
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44th Conf. of the Soc. for Imaging Science 
and Technology: May 12-17, 1991, St. Paul, 
Minn. Submit abstract and author’s applica¬ 
tion by Nov. 19, 1990, to Stanley Busman, 
Graphic Research Lab, 3M, 3M Center 201- 
3N-04, St. Paul, MN 55144, phone (612) 733- 
2664, fax (612) 733-0648. 


Dept., Purdue Univ., West Lafayette, IN 
47907 (for the Americas); Ulrich Trottenberg, 
GMD/F1, Schloss Birlinghoven, D-5205 
Sankt Augustin 1, Germany (for Europe and 
Africa); or Toshitugu Yuba, ETL 1-1-4 Ume- 
sono, Tukuba, Ibaraki, 305 Japan (for Japan 
and the Far East). 



1991 ACM Symp. on Personal and Small 
Computers: June 12-14, 1991, Toronto. Co¬ 
sponsors: Nat’l Research Council of Canada et 
al. Submit five copies of paper by Nov. 19, 
1990, to Michael Bauer, Computer Science 
Dept., Middlesex College, Univ. of Western 
Ontario, London, Ont., Canada N6A 5B7, 
e-mail bauer@csd.uwo.ca, bauer@uwovax. 
bitnet. 


(^1 ISCA 18,18th Int’l Symp. on Com- 
puter Architecture: May 27-30, 1991, 
Toronto. Cosponsor: ACM. Submit five cop¬ 
ies of manuscript by Nov. 21, 1990, to John 
Hayes, Electrical Eng. and Computer Science 
Dept., Univ. of Michigan, 1301 Beal A\c., 
Ann Arbor, MI 48109, phone (313) 763-0386. 

Int’l Conf. on Symbolic-Numeric Data 
Analysis and Learning: Sept. 17-20, 1991, 
Paris. Sponsor: Institut National de Recherche 
en Informatique et en Automatique. Submit 
paper by Nov. 30, 1990, to Conf. Secretariat, 
INRIA, Service des Relations Exterieures, 
Domaine de Voluceau — Rocquencourt, BP 
105, 78153 Le Chesnay Cedex, France; phone 
33 (1 )-39-63-55-00, fax 33 (1) 39-63-56-38. 


SID 91,1991 Int’l Symp., Seminar, and Ex¬ 
hibition: May 6-10, 1991, Anaheim, Calif. 
Sponsor: Soc. for Information Display. Sub¬ 
mit abstract and technical summary by Nov. 
30,1990, to Jay Morreale, Palisades Inst, for 
Research Services, 201 Varick St., Suite 1140, 
New York, NY 10014, phone (212) 620-3371, 
fax (212) 620-3379. 


ECOOP 91, Fifth European Conf. on Ob¬ 
ject-Oriented Programming: July 15-19, 
1991, Geneva, Switzerland. Submit five cop¬ 
ies of paper by Nov. 30, 1990, to Pierre Amer¬ 
ica, Philips Research Labs, PO Box 80.000, 
5600 JA Eindhoven, The Netherlands. 


Symp. on Solid Modeling Foundations and 
CAD/CAM Applications: June 5-7, 1991, 
Austin, Texas. Sponsor: ACM SIGGraph. 
Submit five copies of full paper by Nov. 30, 
1990, to Jaroslaw Rossignac, J2-C03, IBM 
T.J. Watson Research Center, PO Box 704, 
Yorktown Heights, NY 10598, phone (914) 
784-7630, fax (914) 784-7455, e-mail jarek 
@ibm.com. 

Int’l J. Computer-Aided VLSI Design plans a 
special issue on hardware accelerators for 
computer-aided design. Publisher: Ablex. 
Submit five copies of full paper by Dec. 1, 
1990, to Ausif Mahmood, Electrical Eng. 
Dept., Washington State Univ. at Tri-Cities, 
100 Sprout Rd., Richland, WA 99352, phone 
(509) 375-9234. 


1991 ACM Int’l Conf. on Supercomputing: 

June 17-21, 1991, Cologne, Germany. Co¬ 
sponsors: Gesellschaft fur Informatik et al. 
Submit five copies of full manuscript by Dec. 
1, 1990, to Elias Houstis, Computer Science 


CBMS 91, Fourth IEEE Symp. on 
Computer-Based Medical Systems: 

May 12-14, 1991, Baltimore. Cosponsors: 
IEEE Computer Society, IEEE Engineering ir 
Medicine and Biology Society, and IEEE Bal¬ 
timore Section. Submit four copies of summa¬ 
ry by Dec. 5, 1990, to Isaac Bankman, Johns 
Hopkins Univ., Applied Physics Lab., Bldg. 
2-257, Johns Hopkins Rd„ Laurel, MD 20723- 
6099, phone (301) 953-5000, ext. 4253, fax 
(301) 953-1093. 

Eurographics 91, Conf. of the European As¬ 
soc. for Computer Graphics: Sept. 2-6, 

1991, Vienna. Submit paper by Dec. 10. 1990, 
to Eurographics 91, c/o Interconvention, Aus¬ 
tria Center A-1450, Vienna, Austria, phone 43 
(1) 2369-2640, fax 43 (1) 2369-648. 

Fifth Israel Conf. on Computer Sys- 
terns and Software Eng.: May 28-29, 
1991, Herzlia, Israel. Sponsors: IEEE Com¬ 
puter Soc. Israeli Chapter et al. Submit four 
copies of extended abstract by Dec. 14, 1990, 
to M. Winokur, c/o ORTRA, PO Box 50432, 
Tel Aviv 61500, Israel, phone 972 (3) 664- 
825, fax 972 (3) 660-952. 

DCC 91, Data Compression Conf.: 
Apr. 8-10, 1991, Snowbird, Utah. Spon¬ 
sor: IEEE Computer Society TCC, NASA/ 
CESDIS. Submit three copies of extended ab¬ 
stract by Dec. 15,1990, to Martin Cohn, Com¬ 
puter Science Dept., Brandeis Univ., Walt¬ 
ham, MA 02254. 

Compsac 91,15th Int’l Software and 
Applications Conf.: Sept. 11-13, 1991, 
Tokyo. Cosponsor: Information Processing 
Society of Japan. Submit six copies of paper 
by Jan. 12, 1991, to Lionel M. Ni. Michigan 
State Univ., Computer Science Dept., A714 
Wells Hall, East Lansing, MI 48824-1027, 
phone (517) 353-4386, fax (517) 336-1061, 
Internet ni@cps.msu.edu (for the Americas, 
Europe, and Africa); or Motoei Azuma, Wase- 
da Univ., c/o Business Center for Academic 
Societies of Japan, 3-23-1 Hongo, Bunkyo-ku, 
Tokyo 113, Japan, phone 81 (3) 817-5831, fax 
81 (3) 817-5836. 

Sixth Int’l Workshop on Software 
Specification and Design: Oct. 25-26, 
1991, Como, Italy. Submit five copies of reg¬ 
ular or position paper by Jan. 21,1991, to 
Carlo Ghezzi, Dip. di Elettronica Politecnico 
di Milano, Piazza Leonardo Da Vinci 32, 
20133 Milano, Italia, e-mail relett24@imipoli. 
bitnet. 


IEEE Trans, on Computers plans a 
special issue on artificial neural net¬ 
works. Submit six copies of manuscript by 
Feb. I, 1991, to Benjamin W. Wah, Coordi¬ 
nated Science Lab, MC228, Univ. of Illinois, 

1101 W. Springfield Ave., Urbana, IL 61801 
3082, phone (217) 333-3516, fax (217) 244- 
1764, e-mail wah%aquinas@uxc.cso.uiuc.edu. 


October 1990 


12th Saudi Nat’l Computer Conf. on Plan¬ 
ning for the Informatics Soc., Oct. 21-24, 

Riyadh, Saudi Arabia. Cosponsors: King Saud 
Univ., Saudi Computer Soc. Contact Moham¬ 
mad M. Mandurah, College of Computer and 
Information Sciences, PO Box 51178, Riyadh, 
11543, Saudi Arabia, phone 996 (1) 467-6993. 

OOPSLA 90, Fifth Conf. on Object-Orient¬ 
ed Programming Systems, Languages, and 
Applications, Oct. 21-25, Ottawa, Canada. 
Sponsor: ACM. Contact Assoc, for Comput¬ 
ing Machinery, 11 W. 42nd St., New York, 
NY 10036, phone (212) 869-7440. 


^ FOCS, 31st Foundations of Computer 
V Science, Oct. 22-24, St. Louis. Contact 
Christos Papadimitriou, Computer Science 
Dept., Univ. of California at San Diego, La 
Jolla, CA 92093, phone (619) 534-2086. 


Int’l Conf. on Computer Applications in 
Developing Countries, Oct. 22-24, Benin 
City, Nigeria. Sponsor: Large Scale Systems 
Research Group, Univ. of Benin. Contact E.A. 
Onibere, Math, and Computer Science Dept., 
Univ. of Benin, P.M.B. 1154, Benin City, 
Nigeria. 

Ninth Nat’l Conf. on EDP System and Soft¬ 
ware Quality Assurance, Oct. 22-24, Wash¬ 
ington, DC. Sponsor: Data Processing Man¬ 
agement Assoc. Contact US Professional 
Development Inst., EDP System and Software 
Quality Assurance, 1734 Elton Rd., Suite 221, 
Silver Spring, MD 20903-1733, phone (301) 
445-4400, fax (301) 445-5722. 


N JCIT 5, Fifth Jerusalem Conf. on In 
7 formation Technology, Oct. 22-25, 

Jerusalem. Sponsor: Information Processing 
Assoc, of Israel. Contact Abraham Peled, IBM 
T.J. Watson Research Center, PO Box 704, 
Yorktown Heights, NY 10598. 


Second Int’l Machinery Monitoring and Di¬ 
agnostics Conf., Oct. 22-25, Los Angeles. 
Sponsors: Union College, Schenectady, N.Y.; 
Soc. for Experimental Mechanics. Contact 
Union College, Wells House, 1 Union Ave., 
Schenectady, NY 12308, phone (518) 370- 
6673, fax (518) 370-6875. 


CC 90, Third Int’l Workshop on Compiler 
Compilers, Oct. 22-26, Schwerin, East Ger¬ 
many. Sponsors: German Democratic Repub¬ 
lic Academy of Sciences Inst, of Informatics 
and Computing Technique et al. Contact 
Michael Albinus, CC 90 Organizing Commit¬ 
tee, Akademie der Wissenschaften der DDR, 
Inst, fur Informatik und Rechentechnik, Ru- 
dower Chaussee 5, Berlin, GDR — 1199. 


102 


COMPUTER 










CALENDAR 


In the accompanying Calendar, the IEEE Computer Society logo identi- 
ties the conferences the society is sponsoring or participating in. Other 
conferences of interest to our readers, as well as their sponsors, are also listed. 

For inclusion in Call for Papers or Calendar, submit the following information: 
event name, date(s), location, and sponsor(s) as well as the phone and fax num¬ 
bers and the electronic address of the person to contact. In addition, for Calls for 
Papers listings, include the name of the person to whom papers should be submit¬ 
ted and the deadline for submittals. 

Computer should receive the above-mentioned information at least five weeks 
before the month of publication (i.e., for the December 1990 issue, send infor¬ 
mation for receipt by October 22,1990) to Chuck Governale, Calendar Dept., 
Computer, PO Box 3014, Los Alamitos, CA 90720-1264. 


Third Int’l Symp. on Artificial Intelligence, 
Oct. 22-26, Monterrey, N.L. Mexico. Spon¬ 
sors: Inst. Tecnologico y de Estudios Superi- 
ores de Monterrey et al. Contact Hugo Terash- 
ima, Centro de Inteligencia Artificial, ITESM, 
Sue. de Correos “J”, C.P. 64849 Monterrey, 
N.L. Mexico, phone 52 (83) 58-2000, fax 52 
(83) 58-0771, e-mail isai@tecmtyvm.bitnet. 

Lecture Series on High-Integrity Systems, 
Oct. 23, Gaithersburg, Md. Sponsor: Nat’l 
Inst, of Standards and Technology. Contact 
Dolores Wallace, NIST, Bldg., B266, Gaith¬ 
ersburg, MD 20899, phone (301) 975-3340, 
e-mail wallace@swe.swe.ncsl.nist.gov. 

Visualization 90, Oct. 23-26, San Fran¬ 
cisco. Contact Bruce Brown, Oracle 
Corp., 20 Davis Dr., Belmont, CA 94002, 
phone (415)598-3628. 


NACLP 90, 1990 North Am. Conf. on 
Logic Programming, Oct. 28-Nov. I, 

Austin, Texas. Cosponsor: ACM. Contact 
Carlo Zaniolo, MCC, 3500 W. Balcones Cen¬ 
ter Dr., Austin, TX 78759, phone (512) 338- 
3442. 

Int’l Conf. on Information Technology, 

Oct. 29-31, Bournemouth, UK. Sponsor: Insti¬ 
tution of Electrical Engineers. Contact Conf. 
Services, IEE, Savoy Place, London WC2R 
0BL, t)K, phone 44 (71) 240-1871, fax 44 
(71) 240-^735. 

Eighth Pacific Northwest Software Quality 
Conf., Oct. 29-31, Portland, Ore. Sponsor: 
Pacific Northwest Software Quality Conf. 
Committee. Contact Terri Moore, Pacific 
Agenda, PO Box 10142, Portland, OR 97210, 
phone (503) 223-8633. 


10th Int’l Workshop on Distributed Artifi¬ 
cial Intelligence, Oct. 23-27, Bandera, Texas. 
Cosponsors: Am. Assoc, for Artificial Intelli¬ 
gence, MCC. Contact Michael N. Huhns, 

MCC 3500 W. Balcones Center Dr., Austin, 
TX 78759, phone (512) 338-3651. 

ESORICS 90, European Symp. on Research 
in Computer Security, Oct. 24-26, Toulouse, 
France. Sponsor: AFCET. Contact Martin 
Gilles, 16 Para de Diane, 78350 Jouy eu Josas, 
Toulouse Cedex, France. 

First Japanese Knowledge Acquisition for 
Knowledge-Based Systems Workshop, Oct. 
25-26, Kyoto, Japan, and Oct. 29-31, Tokyo. 
Cosponsors: Kansai Inst, of Information Sys¬ 
tems et al. Contact John H. Boose, Advanced 
Technology Center, Boeing Computer Ser¬ 
vices 7L-64, PO Box 24346, Seattle, WA 
98124, phone (206) 865-3253. 

Integrated Systems Conf., Oct. 28-31, San 

Antonio, Texas. Sponsor: Inst, of Industrial 
Engineers. Contact HE, 25 Technology Park/ 
Atlanta, Norcross, GA 30092, phone (404) 
449-0460, fax (404) 263-8532. 


ISCIA 5, Fifth Int’l Symp. on Computer 
and Information Sciences, Oct. 30-Nov. 2, 
Cappadocia, Nevsehir, Turkey. Sponsors: 
Istanbul Tech. Univ. et al. Contact A. Emre 
Harmanci, Istanbul Tech. Univ., Bilgi lslem 
Merkezi, Ayazaga, 80626 Istanbul, Turkey, 
phone 090 (1) 176-3254, fax 090 (1) 176- 
1734, e-mail harmanci@tritu.bitnet. 

Compsac 90,14th Int’l Computer 
Software and Applications Conf., Oct. 
31-Nov. 2, Chicago. Contact Ifay F. Chang, 
Rm. 1B28, IBM T.J. Watson Research Center, 
PO Box 714, Yorktown Heights, NY 10598, 
phone (914) 789-7825, fax (914) 784-6211. 


November 1990 


14th SCAMC, 1990 Symp. on Computer 
Applications in Medical Care, Nov. 4-7, 

Washington, DC. Cosponsors: George Wash¬ 
ington Univ. Medical Center et al. Contact 
SCAMC — Office of CEM, George Washing¬ 
ton Univ. Medical Center, 2300 K St. NW, 


Washington, DC 20037, phone (202) 994- 
8928. 

ICCC 90,10th Int’l Conf. on Computer 
Comm., Nov. 4-8, New Delhi, India. Sponsor: 
Int’l Council on Computer Comm. Contact 
Saroj Chowla, ICCC 90, CMC Ltd., A-5 Ring 
Rd., South Extension Part I, New Delhi 
110049, India, phone 91 (11) 626-807, fax 91 
(11)684-4652. 

Optcon 90, Applications in Optical Science 
and Eng. Conf., Nov. 4-9, Boston. Cospon¬ 
sors: IEEE Lasers and Electro-Optics Soc. et 
al. Contact SPIE, PO Box 10, Bellingham, 

WA 98227-0010, phone (206) 676-3290, fax 
(206) 647-1445. 

1990 IFIP-IEEE Int’I Workshop on 
Defect and Fault Tolerance in VLSI 
Systems, Nov. 5-7, Grenoble, France. Contact 
Gabriel Saucier, Inst. Nat’l Polytechnique de 
Grenoble/CSI, 46 avenue Felix-Viallet, 38031 
Grenoble Cedex, France, phone (33) 76-57- 
46-87, fax (33) 76-50-23-21; or Tulin E. Man- 
gir, TRW, 1 Space Park, R2/2036, Redondo 
Beach, CA 90278, phone (213) 813-3894, fax 
(213)813-3709. 

24th Asilomar Conf. on Signals, Systems, 
and Computers, Nov. 5-7, Pacific Grove, Ca¬ 
lif. Sponsors: Naval Postgraduate School et al. 
Contact George M. Dillard, Naval Ocean Sys¬ 
tems Center, San Diego, CA 92152-5000, 
phone (619) 553-2478. 

Forte 90, Third Int’l Conf. on Formal De¬ 
scription Techniques, Nov. 5-8, Madrid. 
Contact Juan Quemada, Ingenieria Telematica 
Dept., ETSI Telecomunicacion, E-28028, 
Madrid, Spain, phone 34 (1) 549-5700, fax 34 
(1) 243-2077, e-mail jquemada@dit.upm.es. 

ICCS 90, Int’l Conf. on Comm. Systems, 
Nov. 5-9, Singapore. Cosponsors: IEEE Sin¬ 
gapore Section et al. Contact ICCS 90, c/o 
Meeting Planners Pte. Ltd., 100 Beach Rd. 
#33-01, Shaw Towers, Singapore 0718. 

Second SIAM Conf. on Linear Algebra in 
Signals, Systems, and Control, Nov. 5-9, San 
Francisco. Contact Soc. for Industrial and Ap¬ 
plied Math., 3600 University City Science 
Center, Philadelphia, PA 19104-2688, phone 
(215) 382-9800, fax (215) 386-7999, e-mail 
siamconfs@wharton.upenn.edu. 

Second NASA Symp. on VLSI Design, Nov. 

6, Moscow, Idaho. Contact Judy Wood, 

NASA SERC, College of Eng., Univ. of Ida¬ 
ho, Moscow, ID 83843, phone (208) 885- 
6500, fax (208) 885-6645. 

Intelligent Robotic Systems: Design and 
Applications, Nov. 6-7, Philadelphia. Spon- 
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sor: SPIE. Contact Mohan M. Trivedi, Univ. 
of Tennessee, Electrical and Computer Eng., 
Ferris Hall, Knoxville, TN 37996-2100, phone 
(615) 974-5450. 

ACM Conf. on Critical Issues, Nov. 6-7, Ar¬ 
lington, Va. Contact Jim Adams, ACM, 11 W. 
42nd St., New York, NY 10036, phone (212) 
869-7440, fax (212) 869-1228. 

Gomac 90,1990 Govt. Microcircuit Appli¬ 
cations Conf., Nov. 6-8, Las Vegas. Cospon¬ 
sors: US Defense Dept, et al. Contact Ran¬ 
dolph A. Reitmeyer, USALABCOM, Elec¬ 
tronics Technology and Devices Lab, ATTN: 
SLCET-I, Ft. Monmouth, NJ 07703-5000, 
phone (201) 544-3465. 

/£j^| TAI 90, Second Computer Soc. Int’l 
Conf. on Tools for Artificial Intelli¬ 
gence, Nov. 6-9, Washington, DC. Cospon¬ 
sors: Rutgers Univ. et al. Contact Nikolas G. 
Bourbakis, IBM, 5600 Cottle Rd., San Jose, 
CA 95193, phone (408) 270-3455. 

IEEE Workshop on the Management 
of Replicated Data, Nov. 7-9, Houston. 
Sponsor: IEEE Computer Soc. Tech. Commit¬ 
tee on Operating Systems. Contact Luis-Felipe 
Cabrera, IBM Almaden Research Center, 650 
Harry Rd., MC K55/803, San Jose, CA 95120- 
6099, phone (408) 927-1838. 

1990 IEEE Workshop on VLSI Signal Pro¬ 
cessing, Nov. 7-9, San Diego, Calif. Contact 
Patti Fenstermacher, AT&T Bell Labs, 1243 
S. Cedar Crest Blvd., Allentown, PA 18103, 
e-mail psf@aloft.att.com; or Howard S. 
Moscovitz, AT&T Bell Labs, 1243 S. Cedar 
Crest Blvd., Allentown, PA 18103, e-mail 
mosc@aloft.att.com. 

Int’l Workshop on Network and Operating 
System Support for Digital Audio and Vid¬ 
eo, Nov. 8-9, Berkeley, Calif. Sponsor: Int’l 
Computer Science Inst. Contact Ramesh 
Govindan, ICSI, 1947 Center St., Suite 600, 
Berkeley, CA 94704-1105, phone (415) 642- 
4274, ext. 136, e-mail av-workshop@ 
berkeley.edu. 

Computational Science in Industry and the 
Comprehensive Univ., Nov. 8-10, Pomona, 
Calif. Sponsor: Calif. State Polytechnic Univ. 
at Pomona. Contact Bruce P. Hillam, Comput¬ 
er Science Dept., Calif. State Polytechnic 
Univ., 3801 W. Temple Ave., Pomona, CA 
91768, phone (714) 869-3440. 

Fourth Southeastern Small-College Com¬ 
puting Conf., Nov. 9-10, Hickory, N.C. 
Sponsor: Consortium for Computing in Small 
Colleges. Contact Susan Dean, Samford 
Univ., 800 Lakeshore Dr., Birmingham, AL 
35229, Bitnet stdean@samford.bitnet. 

|£gj| ICCAD 90, IEEE Int’l Conf. on Com- 
puter-Aided Design, Nov. 12-15, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Soc. Contact Pat Pistilli, MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boulder, 
CO 80301, phone (303) 530-4562 or 4333. 

Autofact 90, Robots 14, and Vision 90, Nov. 
12-15, Detroit. Cosponsors: Soc. of Manufac¬ 


turing Engineers and SME Machine Vision 
Assoc. Contact SME Conf. Dept., PO Box 
930, Dearborn, MI, phone (313) 271-1500, 
ext. 369. 

Int’l Conf. on Applications of Software 
Measurement, Nov. 12-15, San Diego, Calif. 
Sponsor: Am. Soc. for Quality Control. Con¬ 
tact Software Quality Eng., 3000-2 Hartley 
Rd., Jacksonville. FL 32257, phone (904) 268- 
8639. 

|£3^| Supercomputing 90, Nov. 12-16, New 

York City. Cosponsor: ACM. Contact 
Joanne L. Martin, IBM T.J. Watson Research 
Center, PO Box 218, Route 134, Yorktown 
Heights, NY 10598, phone (914) 945-3285, 
e-mail jlmart@ibm.com; or Supercomputing 
90, IEEE Computer Soc., 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone(202) 371-1013. 

Second Int’l Symp. on Electronic Art, Nov. 
12-17, Groningen, Holland. Sponsor: Gronin¬ 
gen Polytechnic. Contact SISEA, Wester- 
havenstraat 13,9718 AJ Groningen, Holland, 
phone 31 (50) 138160, fax 31 (50) 138242.. 

Seventh Governor’s Symp. on High 
Technology, Nov. 13-15, Kauai, Ha¬ 
waii. Sponsor: State of Hawaii. Contact Willi¬ 
am M. Ball, State of Hawaii, 300 Kahelu St., 
Suite 35, Mililani, HI 96789, phone (808) 
625-5293. 

PRICAI 90, Pacific Rim Int’I Conf. 
on Artificial Intelligence 90, Nov. 14- 

16, Nagoya-shi, Aichi, Japan. Sponsor: Japa¬ 
nese Soc. for Artificial Intelligence et al. Con¬ 
tact Teruo Fukumura, Inter Group Corp., 
Akasaka Yamakatsu Bldg., 8-5-32 Akasaka, 
Minato-ku, Tokyo 107, Japan, phone (03) 
479-5535. 

Third North Carolina Symp. on Arti- 
ficial Intelligence, Nov. 15-16, Re¬ 
search Triangle Park, N.C. Cosponsors: IEEE 
Computer Soc. of Eastern North Carolina et 
al. Contact Connie McElroy-Bacon or Belinda 
Niedwick, Div. for Lifelong Education, North 
Carolina State Univ., Box 7401, Raleigh, NC 
27695-7401, phone (919) 737-2261. 

Cognitiva 90, Nov. 20-23, Madrid. 
Sponsor: AFCET. Contact Cognitiva 
90, c/o Assoc. Francaise pour la Cybemetique 
Economique et Technique, 156 Bd. Pereire, 
75017 Paris, France, phone 33 (1) 4766-2419, 
fax 33 (1)4267-9312. 

IFIP Workshop on Electronic Design 
Automation Frameworks, Nov. 26-28, 
Charlottesville, Va. Sponsor: Int’l Federation 
for Information Processing. Contact Ron 
Waxman, Univ. of Virginia, Thornton Hall, 
Charlottesville, VA 22903, phone (804) 924- 
6086. 

/£j^| IEEE 1990 Conf. on Software Mainte- 
nance, Nov. 26-29, San Diego, Calif. 
Contact Thomas M. Pigoski, USN, NSGD 
Pensacola, Corry Station, Pensacola, FL 
32511, phone (904) 452-6399. 


Micro 23, 23rd Symp. and Workshop 
on Microprogramming and Microar¬ 
chitecture, Nov. 27-29, Orlando, Fla. Co¬ 
sponsor: ACM. Contact Chris Papachristou, 
Case Western Reserve Univ., Computer Eng. 
and Science Dept., Cleveland, OH 44106, 
phone (216) 368-5277, e-mail cap@alpha.ces. 
cwru.edu. 


December 1990 


First Int’l Symp. on Uncertainty and 
Analysis: Fuzzy Reasoning, Probabi¬ 
listic Methods, and Risk Management, Dec. 
3-5, College Park, Md. Sponsors: Univ. of 
Maryland et al. Contact Bilal M. Ayyub, Civil 
Eng. Dept., Univ. of Maryland, College Park, 
MD 20742, phone (301) 405-1956. 

|£jj| ICCV 90, Third Int’l Conf. on Com 
puter Vision, Dec. 4-7, Osaka, Japan. 
Contact ICCV 90, IEEE Computer Soc., 1730 
Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 

11th Real-Time Systems Symp., Dec. 
vSP' 5-7, Orlando, Fla. Sponsor: IEEE Com¬ 
puter Soc. Tech. Committee on Real-Time 
Computing. Contact Doug Locke, IBM — MS 
409, Systems Integration Div., 6600 Rock- 
ledge Dr., Bethesda, MD 20817, phone (301) 
493-1496, e-mail cdl@cs.cmu.edu. 

CASE 90, Fourth Int’l Workshop on 
Computer-Aided Software Eng., Dec. 
5-8, Irvine, Calif. Contact Elliott J. Chikofsky, 
Radius Systems, 75 Lexington St., Burlington, 
MA 01803, phone (617) 494-8200. 

WSC 90,1990 Winter Simulation 
'A' Conf., Dec. 9-12, New Orleans. Contact 
Randall P. Sadowski, Systems Modeling 
Corp., 504 Beaver St., Sewickley, PA 15143, 
phone (412) 741-3727. 

Second IEEE Symp. on Parallel and 
Distributed Processing, Dec. 9-13, 

Dallas. Cosponsor: Dallas Chapter of the 
IEEE Computer Soc. Contact Behrooz Shirazi, 
Computer Science Dept., Southern Methodist 
Univ., 6425 Airline Rd., Dallas, TX 75275- 
0122, phone (214) 692-2874, e-mail shirazi% 
smu.uucp@uunet.uu.net. 

(jjjjh San Diego Workshop on Volume Vi- 
sualization, Dec. 10-12, La Jolla, Calif. 
Cosponsor: ACM. Contact T. Todd Elvins, 
SDSC, Box 85608, San Diego, CA 92038, 
phone (619) 534-5128. 

1990 IEEE Workshop on Languages 
and Architectures for Automation, 
Dec. 19-21, Honolulu. Sponsors: Pacific Int’l 
Center for High Technology Research et al. 
Contact D.Y.Y. Yun, Univ. of Hawaii, 711 
Kapiolani Blvd., Suite 200, Honolulu, HI 
96813-5249, phone (808) 539-1532, fax (808) 
941-1399; or Shi-Kuo Chang, 322 Alumni 
Hall, Univ. of Pittsburgh, Pittsburgh, PA 
15260, phone (412) 624-8493, fax (412) 624- 
8465, e-mail chang@vax.cs.pitt.edu. 
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January 1991 


March 1991 


|£3^l Fourth CSI/IEEE Int’l Symp. on 
'5*7 VLSI Design, Jan. S-8, New Delhi, In¬ 
dia. Sponsors: Computer Soc. of India et al. 
Contact Yashwant K. Malaiya, Computer Sci¬ 
ence Dept., Colorado State Univ., Fort Col¬ 
lins, CO 80523, phone (303) 491-7031, fax 
(303) 491-2293, e-mail malaiya@ravi.cs. 
colostate.edu; or D. Roy Chowdhury, Gate¬ 
way Design Automation, SDF#A-1, Noida Ex¬ 
port Processing Zone, PO NEPZ, Noida 
201305, India, phone 91 (05736) 62342, fax 
91 (05736)62343. 

Int’l Workshop on Formal Methods 

in VLSI Design, Jan. 9-11, Puerto 
Rico. Cosponsors: ACM, IFIP. Contact P.A. 
Subrahmanyam, Rm. 4E-530, AT&T Bell 
Labs, Holmdel, NJ 07733, phone (201) 949- 
5812, fax (201) 949-3697, e-mail subra@ 
vaxl35 .att.com. 

Int’l Conf. on Multimedia Informa¬ 
lly tion Systems, Jan. 16-18, Singapore. 
Contact Desai Narasimhalu or Juzar Motiwal- 
la, Inst, of Systems Science, Nat’l Univ. of 
Singapore, Heng Mui Keng Terr., Kent Ridge, 
Singapore 0511, phone (65) 772-2075, fax 
(65) 772-2002, Bitnet issad@nusvm. 

PADS, Workshop on Parallel and 

Distributed Simulation, Jan. 21-23, 

Anaheim, Calif. Cosponsors: ACM, SCS. 
Contact David M. NicOl, Computer Science 
Dept., College of William and Mary, Wil¬ 
liamsburg, VA 23185, phone (804) 221-3458, 
e-mail nicol@cs.wm.edu. 

IEEE Int’l Conf. on Wafer Scale Inte- 
^7 gration, Jan. 29-31, San Francisco. Co¬ 
sponsors: IEEE Components, Hybrids, and 
Manufacturing Technology Soc. Contact Ter¬ 
ry Chappell, 730 Encino Dr., Aptos, CA 
95003, phone (408) 662-1936; or R. Mike 
Lea, Brunei Univ., Uxbridge UB8 3PH, UK, 
phone (44) 895-74000, ext. 2821, fax (44) 
895-58728, e-mail mike.lea@brunel.ac.uk. 


February 1991 

CAIA 91, Seventh IEEE Conf. on Ar- 
'^1^' tificial Intelligence Applications, Feb. 
24-28, Miami Beach, Fla. Contact IEEE Com¬ 
puter Soc., 1730 Massachusetts Ave, NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

| ^f^| EDAC 91, European Design Automa- 
vtZ (ion Conf., Feb. 25-28, Amsterdam. 
Sponsor: Institution of Electrical Engineers. 
Contact Secretariat, EDAC 91, CEP Consult¬ 
ants, 26-28 Albany St., Edinburgh EH1 3QH, 
Scotland, phone 44 (31) 557-2478, fax 44 (31) 
557-5749. 

Compcon Spring 91, Feb. 25-Mar. 1, 

San Francisco. Contact Compcon 
Spring 91, IEEE Computer Soc., 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 


|£|^j Fifth Int’l Workshop on High-Level 
Kjy Synthesis, Mar. 3-6, Buhlerhohe, West 
Germany. Cosponsors: IEEE et al. Contact 
Raul Camposano, IBM T.J. Watson Research 
Center, PO Box 218, Yorktown Heights, NY 
10598, phone (914) 945-3871, e-mail raulc@ 

Fourth Computer Virus and Security 
Conf., Mar. 14-15, New York City. 
Sponsor: Data Processing Management Assoc. 
Financial Industries. Contact Judy S. Brand, 
PO Box 6313, FDR Station, New York, NY 
10150, phone (800) 835-2246. 

Symp. on Experiences with Distribu- 
ed and Multiprocessor Systems, Mar. 
21-22, Atlanta. Sponsor: Usenix Assoc. Con¬ 
tact George Leach, AT&T Paradyne, MS LG- 
129, PO Box 2826, Largo, FL 34649-2826, 
phone (813) 530-2376, e-mail reggie@pdn. 
paradyne.com. 


April 1991 


Dasfaa 91, Second Int’l Symp. on Da- 
tabase Systems for Advanced Appli¬ 
cations, Apr. 2-4, Tokyo. Sponsor: Informa¬ 
tion Processing Soc. of Japan. Contact Yahiko 
Kambayashi, Computer Science Dept., Ky¬ 
ushu Univ., 6-10-1 Hakozaki, Higashi Fukuo¬ 
ka 812, Japan, phone 81 (92) 641-1101, ext. 
5407; or Yoshifumi Masunaga, Univ. of Li¬ 
brary and Information Science, 1-2 Kasuga, 
Tsukuba, Ibaraki 305, Japan, phone 81 (298) 
52-0511, ext. 340, fax 81 (298) 52-4326, e- 
mail masunaga@ ulis.ac.jp. 

SAC 91,1991 Symp. on Applied Com¬ 
ply' puting, Apr. 3-5, Kansas City, Mo. 
Sponsor: Univ. of Missouri — Kansas City. 
Contact Richard G. Hetherington, SAC 91, 
Univ. of Missouri — Kansas City, Computer 
Science Telecommunications Program, 5100 
Rockhill Rd„ Kansas City, MO 64110-2499, 
phone (816) 235*2399. 

® IEEE Infocom 91, Conf. on Computer 
Comm., Apr. 7-11, Miami, Fla. Co¬ 
sponsors; IEEE Computer Soc. and Comm. 
Soc. Contact N. Shacham, IEEE Infocom 91, 
SRI Int’l, 333 Ravenswood Ave., Menlo Park, 
CA 94025, phone (415) 859-5710, e-mail 
shacham@sri.com. 

IMS 91, First IEEE Int’l Workshop 
on Interoperability in Multidatabase 
Systems, Apr. 8-9, Kyoto, Japan. Contact 
Ahmed K. Elmagarmid, Purdue Univ., Com¬ 
puter Sciences Dept., West Lafayette, IN 
47907, phone (317) 494-1998; or Yutaka Mat¬ 
sushita, Instrumentation Dept., Keio Univ., 
Hiyoshi, Yokohama, Japan, phone 81 (44) 63- 
1141, ext. 3564. 

^3^. DCC 91, Data Compression Conf., 
Apr. 8-10, Snowbird, Utah. Sponsor: 
IEEE Computer Society TCC, NASA/CES- 
DIS. Contact John H. Reif, Computer Science 


ASPLOS 4, Fourth Int’l Conf. on Ar- 
vip' chitectural Support for Programming 
Languages and Operating Systems, Apr. 8- 

11, Santa Clara, Calif. Sponsor: ACM. Con¬ 
tact Bob Rau, Hewlett-Packard Labs, 1501 
Page Mill Rd., Bldg. 3U, Palo Alto, CA 
94304, fax (415) 857-8558, e-mail rau@ 
hplabs.hp.com. 

Seventh Int’l Conf. on Data F.ng., 

Apr. 8-12, Kobe, Japan. Contact Ming 
T. (Mike) Liu, Computer and Information Sci¬ 
ence Dept., Ohio State Univ., 2036 Neil Ave., 
Columbus, OH 43210-1277, phone (614) 292- 
1837, e-mail liu@cis.ircc.ohio-state.edu; or 
Data Eng. 91, IEEE Computer Soc., 1730 
Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013, fax (202) 
728-0884. 

® ETC 91,1991 European Test Conf., 
Apr. 10-12, Munich, West Germany. 
Sponsor: VDE (Zentralstelle Tagungen und 
Seminare). Contact Peter Stilke, VDE, Strese- 
mannallee 15, D-6000 Frankfurt 70, West 
Germany, phone (69) 6308-203, fax (69) 
6308-273. 

Ninth IEEE VLSI Test Symp., Apr. 
16-18, Atlantic City, N.J. Cosponsor: 
IEEE Philadelphia Section. Contact Mukund 
Modi, Naval Air Eng. Center, ATE Software 
Center, Code: 52514, Lakehurst, NJ 08733, 
phone (201) 323-7002, fax (301) 323-7445. 

CHDL 91, 10th Int’l Symp. on Com- 
puter Hardware Description Lan¬ 
guages and their Applications, Apr. 22-24, 

Marseille, France. Cosponsors: Int’l Federa¬ 
tion for Information Processing et al. Contact 
Dominique Borrione, Imag/Artemis, BP 53X, 
38041 Grenoble Cedex, France, phone (33) 
7651-4604, ext. 5240, fax (33) 7651-9637, 
e-mail borrione@imag.imag.fr. 

Second Int’l Conf. on Systems Inte- 
gration, Apr. 22-25, Morristown, N.J. 
Cosponsors: New Jersey Inst, of Technology 
et al. Contact Peter A. Ng, Computer and In¬ 
formation Science Dept., New Jersey Inst, of 
Technology, University Heights, Newark, NJ 
07102, phone (201) 596-3387, e-mail ng_p@ 
vienna.njit.edu. 

NCGA 91,1991 Nat’l Computer Graphics 
Assoc. Conf., Apr. 22-25, Chicago. Contact 
NCGA, 2722 Merrilee Dr., Suite 200, Fairfax, 
VA 22031, phone (703) 698-9600. 

CHI 91,1991 Conf. on Human Fac- 
tors in Computing Systems, Apr. 27- 

May 2, New Orleans. Sponsor: ACM. Contact 
Keith Butler, Boeing, Advanced Technology 
Center, PO Box 24346, M/S 7L-64, Seattle, 
WA 98124, phone (206) 865-3389; or June 
Davis, 13 Annapolis St., Annapolis, MD 
21401, phone (301) 269-6801. 

Int’l Conf. on Cognitive Sciences, 
V&y Apr. 29-May 2, Montreal. Cosponsors: 
AFCET et al. Contact Gilles Gauthier, Math. 
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SECOND PHYSICAL DESIGN WORKSHOP 


Module Generation and Silicon Compilation 


Nemacolin Woodlands, Laurel Highlands, Pennsylvania, USA 
May 20-22, 1991 

Sponsored by ACM’s SIGDA 

FIRST CALL FOR PARTICIPATION 



You are invited to participate in the Second Physical Design Workshop to be held at The Nemacolin 
Woodlands Conference Center in the Laurel Highlands outside Pittsburgh, Pennsylvania on May 20- 
22, 1991. Presentations will focus in IC physical design with emphasis on recent developments in 
module generation and silicon compilation including: 

• layout from netlists 

• layout to/ffom schematics 

• layout from behavioral HDL’s 

• performance driven layout 

• experiences with silicon compilation 

• layout benchmark results 


The workshop will be limited in the number of attendees. 


To facilitate comparison of results a set of standard benchmark circuits will be distributed by De¬ 
cember 1990. Please contact the Benchmark Chair to obtain more information about the benchmarks 
for the workshop. 


Participants wishing to deliver a presentation should submit 14 copies of a manuscript whose length 
does not exceed 3000 words, apart from figures, indicating the status of the work and significant 
results. Proposals will be reviewed by the Technical Program Committee. Proceedings will be pub¬ 
lished and distributed at the workshop. The submission deadline is January 7, 1991. 


WORKSHOP DEADLINES 


Jan. 7, 1991 
Feb. 11, 1991 
March 11, 1991 
May 1, 1991 


Last day to receive proposals 
Notification of acceptance 
Camera-ready copy due 
Last day to receive proposals for 
presentation of benchmark results 


For further information contact: 


Workshop Chair 
Antun Domic 
HL02-3/J3 
DEC 

77 Reed Rd. 

Hudson, MA 01749 
domic@cadsys.dec.com 


Program Chair 
Mary Jane Irwin 
333 Whitmore Lab 
Dept, of Cmp. Science 
Penn State Univ. 

Univ. Park, PA 16802 
mji@cs.psu.edu 


Benchmark Chair 
Dwight Hill 

AT&T Bell Labs 
600 Mountain Ave. 
Murray Hill, NJ 07974 
dwight@allegra.att.com 


Arrangements Chair 
Steven Levitan 
348 Benedum Hall 
Dept, of Elec. Engr. 
Univ. of Pittsburgh 
Pittsburgh, PA 15261 
levitan@ee.pitt.edu 





and Computer Science Dept., Univ. of Que¬ 
bec, PO Box 8888, Station A, Montreal, Que., 
Canada H3C 3P8, phone (514) 987-8212, fax 
(514) 987-8477. 


May 1991 


CBMS 91, Fourth IEEE Symp. on 
Computer-Based Medical Systems, 
May 12-14, Baltimore. Cosponsors: IEEE 
Computer Society, IEEE Engineering in Med¬ 
icine and Biology Society, and IEEE Balti¬ 
more Section. Contact Jeffery C. Lesho, Johns 
Hopkins Univ., Applied Physics Lab., Bldg. 
2-257, Johns Hopkins Rd., Laurel, MD 20723- 
6099, phone (301) 953-5000, ext. 8057. 

ICSE 13,13th Int’l Conf. on Software 
Eng., May 13-17, Austin, Texas. Co¬ 
sponsor: ACM. Contact ICSE 13, Bryan Fu¬ 
gate, MCC, 3500 W. Balcones Center Dr., 
Austin, TX 78759-6509, phone (512) 338- 
3330; MCC, PO Box 200015, Austin, TX 
78720-0015; or ICSE 13, IEEE Computer 
Soc., 1730 Massachusetts Ave. NW, Washing¬ 
ton, DC 20036-1903, phone (202) 371-1013. 

/£|^j CompEuro 91, IEEE Int’l Conf. on 
Advanced Computer Technology, Re¬ 
liable Systems, and Applications, May 13- 
17, Bologna, Italy. Cosponsors: IEEE Region 
8 et al. Contact Vito Monaco, Dip. Eletronica 
Informatica E Sistemistica, Univ. Di Bologna, 
Viale Risorgimento, 1-60136, Bologna, Italy. 

CCW 91, Third IEEE Conf. on Com- 
puter Workstations, May 15-17, Fal¬ 
mouth, Mass. Sponsor: IEEE Computer Soc. 
Tech. Committee on Operating Systems. Con¬ 
tact Luis-Felipe Cabrera, IBM Almaden Re¬ 
search Center, MC K55/801, 650 Harry Rd., 
San Jose, CA 95120-6099, phone (408) 927- 
1838, e-mail cabrera@ibm.com; or Kenneth 
Kane, Boston Development Center, Sun Micr¬ 
osystems, 2 Federal St., Billerica, MA 01802, 
phone (508) 671-0367, e-mail kkane@east. 


^ Int’l Symp. on Software Reliability 
Eng., May 17-18, Austin, Texas. Co¬ 
sponsors: IEEE Computer Soc. Tech. Com¬ 
mittee on Software Eng. and the Nat’l Aero¬ 
nautics and Space Administration. Contact 
John C. Munson, Computer Science Div., 
Univ. of West Florida, Pensacola, FL 32514, 
phone (904) 474-2989, e-mail jmunson@ 
dcsnet.uwf.edu. 

ICDCS 91,11th Int’l Conf. on Dis- 
tributed Computing Systems, May 
20-24, Arlington, Texas. Contact Bill D. Car- 
roll, Computer Science Eng. Dept., Univ. of 
Texas at Arlington, Box 19015, Arlington, TX 
76019-0015, phone (817) 273-3785, e-mail 
carroll@evax.ari.utexas.edu. 

SESAW, Fourth Software Eng. Stan- 
dard Application Workshop, May 21- 

23, San Diego, Calif. Contact Vera V. Edel- 
stein, Nynex, 500 Westchester Ave., White 
Plains, NY 10604, phone (914) 683-2888. 


Toronto. Cosponsor: ACM. Contact K.C. 
Smith, Univ. of Toronto, Electrical Eng. 
Dept., Toronto, Ont. M5S 1A4, Canada, 
phone (416) 978-5033. 

® Fifth Israel Conf. on Computer Sys¬ 
tems and Software Eng., May 28-29, 

Herzlia, Israel. Sponsors: IEEE Computer 
Soc. Israeli Chapter et al. Contact M. Wino- 
kur, c/o ORTRA, PO Box 50432, Tel Aviv 
61500, Israel, phone 972 (3) 664-825, fax 972 
(3) 660-952 


June 1991 


July 1991 


Berlin. Sponsor: Tech. Univ. Berlin. Contact 
Heinz U. Lemke, Inst, for Tech. Computer 
Science, Sekr CG-FR3-3, Franklinstrasse 28- 
29, D-1000, Berlin 10, Germany, phone 49 
(30) 314-73100; or Michael H. Rhodes, Toshi¬ 
ba America MRI, 280 Utah Ave., South San 
Francisco, CA 94080, phone (415) 875-2909. 


August 1991 


Fourth Int’l Conf. on Industrial and 
vjp' Eng. Applications of Artificial Intelli¬ 
gence and Expert Systems, June 2-5, Kauai, 
Hawaii. Sponsors: ACM et al. Contact Moonis 
Ali, Univ. of Tennessee Space Inst., MS 15, 
B.H. Goethert Pkwy., Tullahoma, TN 37388- 
8897, phone (615) 455-0631, ext. 236, fax 
(615) 454-2354, e-mail alif@utsivl.bitnet. 

CVPR 91, IEEE Computer Soc. Conf. 
on Computer Vision and Pattern Rec¬ 
ognition, June 3-7, Lahaina, Maui, Hawaii. 
Contact Shahriar Negahdaripour, Electrical 
Eng. Dept., Univ. of Hawaii at Manoa, 2540 
Dole St., Honolulu, HI 96822, e-mail 
shahriar@wiliki.eng.hawaii.edu. 

® SCM 3, Third Int’l Software Configu¬ 
ration Management Workshop, June 
12-14, Trondheim, Norway. Cosponsors: 
ACM, et al. Contact Reidar Conradi, Comput¬ 
er Systems and Telematics Div., Norwegian 
Inst, of Technology, N-7034 Trondheim, Nor¬ 
way, phone 47 (7) 593-444; or Peter Feiler, 
Software Eng. Inst., Carnegie Mellon Univ,, 
Pittsburgh, PA 15213-3890, phone (412) 268- 
7790, e-mail phf@sei.cmu.edu. 

DAC 91, 28th ACM/IEEE Design Au- 
tomation Conf., June 16-21, San Fran¬ 
cisco. Contact MP Associates, 7490 Club¬ 
house Rd., Suite 102, Boulder, CO 80301, 
phone (303) 530-4333. 

(^1 FTCS 21, 21st Int’l Symp. on Fault¬ 
'll?' Tolerant Computing, June 25-27, 
Montreal. Sponsor: IEEE Computer Soc. 

Tech. Committee on Fault-Tolerant Comput¬ 
ing. Contact Vinod K. Agarwal, McGill Univ., 
Electrical Eng. Dept., 3480 University St., 
Montreal, Que., Canada H3A 2A7, phone 
(514) 398-7136, fax (514) 398-4470, e-mail 
agarwal@spock.ee.mcgill.ca. 

I ^j^ l Arith 10,10th Symp. on Computer 
Arithmetic, June 26-28, Grenoble, 
France. Cosponsors: ACM et al. Contact Jean- 
Michel Muller, Lab. LIP-IMAC, Ens. Lyon, 
69364 Lyon Cedex 07, France, phone 33 (72) 
72-8229. 


SSD 91, Second Symp. on Large Spa- 
tial Databases, Aug. 28-30, Zurich, 
Switzerland. Contact H.J. Schek, Inst, fdr In¬ 
formation Systeme, Eth Zentrum, 8092 Zur¬ 
ich, Switzerland, phone 41 (1) 254-7240. 


\ CAR 91, Fifth Int’l Symp. on Com- 
7 puter-Assisted Radiology, July 3-6, 


September 1991 

17th Int’l Conf. on Very Large Data 
Bases, Sept. 3-6, Barcelona, Spain. 
Sponsors: IEEE Computer Soc. Tech. Com¬ 
mittee on Data Eng. et al. Contact Guy Lohm- 
an, IBM Almaden Research Center, 650 Harry 
Rd., San Jose, CA 95120, e-mail lohman@ 
ibm.com. 

Compsac 91,15th Int’l Computer 
Software and Applications Conf., 
Sept. 11-13, Tokyo. Cosponsor: Information 
Processing Soc. of Japan. Contact Stephen S. 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335-8006. 


October 1991 


ff f A IEEE Workshop on Visual Motion, 
Oct. 6-9, Princeton, N.J. Contact Tho¬ 
mas S. Huang, Coordinated Science Lab, 

Univ. of Illinois, 1101 W. Springfield Ave., 
Urbana, IL 61801, phone (217) 333-6912. 

1^, CSEE 91, Fifth SEI Conf. on Soft- 
ware Eng. Education, Oct. 7-8, Pitts¬ 
burgh. Contact James E. Tomayko, Software 
Engineering Inst., Carnegie Mellon Univ., 
4500 Fifth Ave., Pittsburgh, PA 15213-3890, 
phone (412) 268-6806, fax (412) 268-5758. 

Workshop on Experimental Distrib- 
uted Systems, Oct. 12, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, 1 Space Park, 
DH2/2328, Redondo Beach, CA 90278, phone 
(213) 764-6033. 

11th Symp. on Mass Storage Systems, 
Oct. 13-17, Monterey, Calif. Contact 
Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268. 

|£2^| RIDT 91, Second Int’l Workshop on 
Raster Imaging and Digital Typogra¬ 
phy, Oct. 14-15, Boston. Contact Robert A. 
Morris, Math and Computer Science Dept., 
Univ. of Massachusetts at Boston, Harbor 
Campus, Boston, MA 02125-3393, phone 
(617) 287-6466. 
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CALL FOR PAPERS 


IEEE INTERNATIONAL CONFERENCE ON COMPUTER DESIGN: 

VLSI IN COMPUTERS & PROCESSORS 

Sponsored by: IEEE Computer Society and IEEE Circuits and Systems Society 

In Cooperation with: IEEE Electronic Devices Society 

ICCD ’91 

Hyatt Regency Cambridge, Cambridge, Massachusetts 
October 14-16, 1991 


The International Conference on Computer Design: VLSI in Computers and Processors covers all aspects of the design and 
implementation of VLSI computer and processor systems. The multi-disciplinary nature of the conference is intended to 
emphasize the interactions among architecture, computer-aided design, design & test, and VLSI technology. Or igin al papers 
are especially solicited in the following areas as they relate to computer and processor design: 

Architecture and Algorithms: Computer Architecture: Concurrent Computers • Digital • Signal and Image Processors • Data 
Base Machines • Graphics Processors • Architectural Support for Operating Systems and Languages • Computer Design: Cache 
and Memory System Design • Processor Design • Computer Arithmetic • Computer Networks • Algorithms: Design and Analysis 
of Algorithms • Parallel Algorithms • Numerical Methods 

Computer-Aided Design: High-Level Synthesis • Silicon Compilation • Automatic Layout: Placement and Routing • Layout 
Verification • Timing Analysis • Logic and Circuit Simulation • Multiprocessor and Parallel Processor • Implementation of CAD 
Algorithms • Dedicated CAD Hardware • Integrated CAD Systems 

Design & Test: Mixed Analog/Digital Design • Design for Testability • Design for Self Test • Testing and Testability Analysis • 
Fault Modeling • Reliable Computing • Design for Reliability 

VLSI & Technology: State of the Art System Integration • Packaging • Wafer-Scale Integration • Environmental Factors • Optical 
Interconnects • VLSI: CMOS • Bipolar • GaAs • Low Temperature • Mixed Technologies • Storage: Optical • Magnetic • 
Semiconductor 

Papers are also solicited which describe innovative features of new products and the overall integration of Technology, 
Architecture, CAD, and Design and Test into the Computer Design Process. 

Instructions to Authors 

Prospective authors are invited to submit a 3-4 page, single spaced summary plus additional pages for key figures, diagrams, 
and references. To be considered for review, the following information must be included: (a) a clear description of the contribution 
and why it is important, (b) original research submissions must state what is novel about the contribution, (c) review and 
tutorial submissions must state the contribution to the multi-disciplinary mission of the conference. Authors should indicate 
the appropriate technical area for their submission: Architecture and Algorithms, Computer-Aided Design, Design and Test or 
VLSI and Technology. 

Submit six (6) copies of summaries, along with the authors’ names, addresses, e-mail addresses and office and home 
telephone numbers, no later than February 1, 1991 to the Technical Program Chair: 

Dwight Hill 

AT&T Bell Laboratories 
3D-446 

Murray Hill, NJ 07974 r ....----......, 

Telephone: 201-582-7766 j □ PLEASE SEND ME MORE INFORMATION ABOUT 

E-mail: dwight@research.att.com : ICCD ’91 ' 

• Proposals for specially organized sessions are solicited. I Name i, : ■ _ / ' ; ' . _j 

Please forward your proposals to the Technical Program j Company 

Chair for review no later than January 2, 1991. j V y 

• Summaries to Technical Program Chair: February 1, 1991. ; Address-— - : -*-r- \ 

• Notification of acceptance: March 31, 1991. ; City/State/Zip- j 

• Final camera-ready paper due June 15, 1991. ; Country__ ____ \ 

• Awards will be presented to the best conference papers. ■ ! 

Send to: ICCD’91 

19 jjy 91 ▲ ' 1730 Massachusetts Avenue, N.W. j 

40_v F^s er^vic e ^ the institute of Electrical Washington, DC 20036-1903 


□ PLEASE SEND ME MORE INFORMATION ABOUT 
ICCD ’91. 

Name :■ - 

Company __ ■ _ 

Address . .. ' _. 

City/State/Zip_ ■ _ 

Country__ ■ _ 

Send to: ICCD’91 

1730 Massachusetts Avenue, N.W. 
Washington, DC 20036-1903 













CAREER OPPORTUNITIES 


RATES: $12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, 
Los Alamitos, CA 90720-1264; (714) 
821-8380; fax (714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may re¬ 
ject any advertisement containing any of 
these phrases or similar ones: "...recent 
college grads...,'' "...1-4 years maximum 
experience...," "...up to 5 years experi¬ 
ence," or "...10 years maximum 
experience." COMPUTER reserves the 
right to append to any advertisement, with¬ 
out specific notice to the advertiser, 
"Experience ranges are suggested mini¬ 
mum requirements, not maximums." 
COMPUTER assumes that, since advertis¬ 
ers have been notified of this policy in 
advance, they agree that any experience re¬ 
quirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


ENGINEER, PRODUCT QUALITY 
ENGINEERING 

Company in Denver, CO specializing in 
development of CAD/CAM and desktop 
publishing systems seeks Engineer, Product 
Quality Engineering to work with marketing, 
development and/or customers to establish 
and confirm software requirements. Follow 
projects through all phases of CAD/CAM 
software development and related applica¬ 
tions, including requirements analysis, 
design, coding, software and hardware 
testing, and product delivery. Perform 
testing activities using C, C-Shell, C++, 
FORTRAN, and Assembly languages on 
UNIX, Domain/OS and VMS operating 
systems. Develop internal software quality 
program and devise software engineering 
standards. Requires B.S. in Electrical 
Engineering and Computer Science or Elec¬ 
trical and Computer Engineering; nine 
months experience in development of soft¬ 
ware testing tools and software testing; work¬ 
ing knowledge of C, C-Shell, C++, and 
FORTRAN; working knowledge of UNIX, 
Domain/OS and VMS operating systems; 
knowledge of internals of operating systems 
and hardware architectures, capabilities and 
limitations; knowledge of software metrics, 
error tracking, data collection methods and 
feedback analysis, verification and valida¬ 
tion. $29,985/year; 8:00 a.m - 5:00 p.m., 
M-F. Respond by resume to Colorado De¬ 
partment of Labor & Employment, Division 
of Employment & Training, 600 Grant St., 
*900, Denver, CO 80203, ATT: Jim Shima- 
da, and referto Job Order No. CO3194015. 


INDIANA UNIVERSITY-PURDUE 

UNIVERSITY AT INDIANAPOLIS 
(IUPUI) 

The Department of Computer and Infor¬ 
mation Science invites applications for a 
tenure track position at the level of assistant 
or associate professor in scientific 
computing/software engineering. The suc¬ 
cessful candidate is expected to be a member 
of a new interdisciplinary group in computa¬ 
tional science, to be developed jointly by the 
Department of Computer and Information 
Science and the Department of 
Mathematical Sciences. 

Applicants must have an earned doctorate 
and strong teaching credentials A demon¬ 
strated record of research is expected at the 
associate professor level. Assistant professor 
candidates must possess exceptional re¬ 
search potential. Special consideration will 
be given to applicants with a strong back¬ 
ground in numerical computation with ex¬ 
pertise and interest in the development of 
“intelligent” software for large-scale scientific 
computing problems. Salary and rank will be 
determined by experience and qualification. 

IUPUI is a rapidly growing comprehensive 
urban university with over 26,000 students. 
The university offers competitive salaries and 
provides excellent fringe benefits. Indianap¬ 
olis is a large, active metropolis and has 
available a dynamic industrial base con¬ 
ducive to joint research and consulting with 
our faculty. The six-hospital Medical Center 
at IUPUI is yet another source of interdis¬ 
ciplinary research for the Department. 

Applications and inquiries should be ad¬ 
dressed to Prof. Raymond C. Y. Chin, 
Chair, Department of Computer and Infor¬ 
mation Science, IUPUI, 1201 East 38th 
Street, Indianapolis, IN 46205-2868. Dead¬ 
line for applications: December 1, 1990. 
Late applications will be considered until 
position is filled. IUPUI is an Equal Oppor¬ 
tunity/Affirmation Action Employer. 
Women and minority candidates are en¬ 
couraged to apply. 


PURDUE UNIVERSITY 
Computer Engineering Faculty Positions 

The School of Electrical Engineering at 
Purdue University seeks outstanding can¬ 
didates in all areas of Computer Engineering 
for research and teaching. Openings are for 
tenure-track faculty at all levels. Active 
research areas include artificial intelligence 
and expert systems; computer communica¬ 
tions networks; computer vision; design 
automation tools; digital signal processor 
system design; distributed algorithms and 
databases; fault-tolerant and testable com¬ 
puting; microprocessor design; natural lan¬ 
guage processing; neural networks; parallel 
processing (architecture, algorithms, operat¬ 
ing systems, compiling, languages, inter¬ 
connection networks, and performance); 
robot vision, sensors and control; software 
engineering; speech processing; and VLSI 
architecture. 


The School has 69 full-time faculty (25 in 
Computer Engineering) and over $9 million 
in funded research projects. In addition to 
the PhD, MSEE and BSEE degrees, the 
School offers a BSCEE (Bachelor of Science 
in Computer and Electrical Engineering) 
which is accredited in both computer engi¬ 
neering and electrical engineering. Comput¬ 
ing facilities available to the faculty include 
the Engineering Computer Network (includ¬ 
ing 10 VAX 11/780’s running UNIX BSD 
4.3, 1 Gould PN 9080, 4 Gould NP l’s, a 
CCI PN 6/32, and 400 Sun workstations), 
the Computing Center’s Cyber-205 and 
ETA-10 supercomputers, a Symbolics LISP 
machine, an IBM 3090/180E, extensive 
graphics facilities, and numerous PC’s. 
Parallel computing facilities include a 
128-node Ncube hypercube, a 48x48 
processor NCR-GAPP processor array, an 
82-processor AT&T Pixel Machine, a 16- 
processor Transputer array, the 30-proces- 
sor PASM Parallel Processor prototype that 
was developed and built at Purdue, and the 
Computing Center’s 4 Sequent Symmetry 
S81. Custom VLSI chip design facilities in¬ 
clude Mentor Graphics software running on 
Apollo Workstations. Equipment in the 
Robot Vision Lab and Computer Vision and 
Image Processing Lab includes a Puma 762 
robot, a Cincinnati Milacron T3-726 robot, a 
K2A Cybermation mobile robot. Image pro¬ 
cessing systems include Gould/DeAnza, 
Comtal, Grinnell, Imaging Technologies. 

Applicants must possess a doctorate 
degree. Send a resume, including a state¬ 
ment of teaching and research interests and 
a list of three (3) references, to: Head, 
School of Electrical Engineering, Purdue 
University, West Lafayette, IN 47907. Pur¬ 
due University is an Equal Opportunity/Af- 
firmative Action employer. 


UNIVERSITY OF NEVADA, RENO 
Chair, Computer Science 

Applications are invited for the new posi¬ 
tion of Chair, Department of Computer Sci¬ 
ence, University of Nevada, Reno. This in¬ 
dividual will not only provide direction in the 
continuing improvement and development 
of the academic program, but also strong 
leadership in the establishment of a signifi¬ 
cant research program. A Ph. D. in computer 
science, computer engineering or a related 
discipline is expected, and the applicant 
should demonstrate an outstanding record 
of teaching and research. 

Write a letter of application including 
names of four references and a detailed 
resume to Prof. Allen Brady, Chair Search 
Committee, Department of Computer Sci¬ 
ence, Mackay School of Mines, University of 
Nevada, Reno, NV 89557 (email: al@tahoe. 
unr.edu). 

The position commences July 1, 1991. 
Applications will be accepted until December 
31, 1990 or subsequently until the position is 
filled. 

Affirmative Action/Equal Opportunity 
Employer. 
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UNIVERSITY OF CALIFORNIA 
AT IRVINE 
Faculty Positions in 
Computer Science 

The Department of Information and 
Computer Science (ICS) is actively recruiting 
faculty AT ALL LEVELS. We have dynamic 
research groups in the areas of computer 
systems design, parallel processing, artificial 
intelligence, computer networks and distri¬ 
buted processing, software, social and man¬ 
agerial analysis of computing, and theory. 
We are continuing to build on these areas of 
strength. We are also interested in develop¬ 
ing new strength in computational biology, 
integrated systems, computer-supported co¬ 
operative work, databases, design tools, and 
model-based reasoning. We will sympatheti¬ 
cally review applications from very strong 
candidates in all areas of computer science. 

We are looking for new faculty with strong 
research records who would thrive in a high¬ 
ly productive but friendly setting, and who 
would like to join us in exploring the nature 
of computing, broadly defined. We specially 
encourage application from exceptionally 
distinguished candidates for senior positions. 

The ICS Department is an independent 
academic unit reporting to the Executive 
Vice Chancellor. ICS faculty emphasize core 
computer science as well as research in 
emerging areas of the discipline, with effec¬ 
tive interdisciplinary ties to colleagues in 
neurobiology, cognitive science, manage¬ 
ment, engineering, and the social sciences. 
The department currently has 30 full-time 
faculty positions and over 120 Ph.D. stu¬ 
dents, with major support from the admini¬ 
stration to expand and to strengthen the re¬ 
search environment. 

Annual research funding from contracts 
and grants from agencies such as DARPA, 
NSF, and ONR, currently total over $6.5 
million. In 1986 the software group was 
awarded a Coordinated Experimental Re¬ 
search (CER) grant from the National Sci¬ 
ence Foundation. This support has fostered 
the creation of a Research Laboratory for 
software fengineering, in which major studies 
of the development and evaluation of soft¬ 
ware technology are undertaken. High 
quality research has also fostered the crea¬ 
tion of a Research Laboratory for computer 
systems design that deals with methodolo¬ 
gies and tools for the design of complex com¬ 
putational systems. A third Research Labor¬ 
atory, in Artificial Intelligence, is planned. 

Department equipment includes approxi¬ 
mately 175 workstations, primarily Sun-3’s 
and Sun-4s. Two large multiprocessor Se- 
quents and a Hypercube are available, as 
well as approximately 300 Macintosh Plus’s 
and IPs. All our major workstations and com¬ 
puters are tied together with networks, which 
are gatewayed to the campus network, and 
from there, to regional, national, and inter¬ 
national networks (Darpa Internet, CSnet, 
Bitnet, etc.). In addition, department mem¬ 
bers have access to campus-wide computing 
resources as well as regional supercomputer 

UC-Irvine is located in Orange County, 
three miles from the Pacific Ocean near 
Newport Beach, and approximately halfway 
between Los Angeles and San Diego. The 
campus is situated in the heart of a national 
center of high-technology enterprise. It is 


growing rapidly and offers exciting profes¬ 
sional and cultural opportunities. Salaries 
and benefits are competitive. Special hous¬ 
ing assistance is available from the university, 
including newly built, for-sale housing within 
short walking distance from the Department. 

Send resumes and names of four refer- 

Chair, Faculty Recruiting Committee 
Department of Information and Computer 
Science 

University of California-Irvine 
Irvine, CA 92717 

The ICS Department has several vacant 
positions and application screening will begin 
immediately upon receipt of curriculum 
vitae. Maximum consideration will be given 
to applications received by January 31, 
1991. 

The University of California is an Affirma¬ 
tive Action/Equal Opportunity Employer. 
The Department of ICS is particularly in¬ 
terested in receiving applications from 
women and minority candidates. 


THE UNIVERSITY OF CINCINNATI 
Electrical and Computer Engineering 
Department 

Applications are solicited for several new 
tenure track faculty positions at all ranks 
starting September 1, 1991. Applicants in all 
areas of computer science and engineering 
are invited to apply, but the following areas 
are of special interest: microprocessor de¬ 
sign, parallel and distributed computing, 
software engineering, operating systems, 
programming languages, VLSI systems, 
computer-aided design, databases, compiler 
design, architecture, optical computing, and 
computer vision. 

The Department offers MS/Ph.D. pro¬ 
gram in computing sciences and computer 
engineering and also offers ABET accredited 
BS degree in computer engineering. Our 
Computer Science and Engineering faculty 
members are actively involved in research in 
architecture, parallel and distributed sys¬ 
tems, operating systems, VLSI design, and 
computer vision. Departmental resources in¬ 
clude a network of SUN Workstations, a VAX 
11/785, a VAX 11/750, a 16-processor 
ES-Kit, and numerous PCs. Every faculty of¬ 
fice has a Sun Workstation and laser printer; 
graduate student offices also have Sun 
Workstations. The department has recently 
filled 14 faculty positions and is engaged in 
an exciting period of further growth. Cur¬ 
rently the department has 30 full-time facul¬ 
ty, 140 full-time graduate students, 400 
undergraduate students, 2 major research 
centers, and 19 full-time staff members. 

All candidates should have a strong com¬ 
mitment to excellence in research and 
teaching and an earned Ph.D. in either 
Computer Science or Computer Engineer¬ 
ing. Please send curricula vitae and the 
names of three references to: Dr. Vik 
Kapoor, Head, Electrical and Computer 
Engineering Department, Mail Location 30, 
University of Cincinnati, Cincinnati, Ohio 
45221-0030. E-mail inquiries should be sent 
to vkapoor@ucecel.ece.uc.edu. 

The University of Cincinnati is an Affir¬ 
mative Action/Equal Opportunity employer 
and encourages and welcomes applications 
from women and minorities. 


CASE INSTITUTE OF TECHNOLOGY 
NORD Professorship in 
Computer Engineering and Science 

The Department of Computer Engineering 
and Science at Case Institute of Technology 
is seeking a nationally recognized scholar 
and researcher to fill the NORD Professor¬ 
ship. This position was recently established 
by the donation of over one and a half mil¬ 
lion dollars, which will provide outstanding 
professional opportunities and a highly com¬ 
petitive salary, together with additional funds 
for travel, graduate student support and 
equipment. The qualifications include a 
Ph.D. in computer science, computer engi¬ 
neering or closely allied fields, and an ability 
to establish and develop external support for 
a nationally recognized research program in 
computer science/computer engineering. 
We invite applications from senior faculty at 
both the associate professor and full pro¬ 
fessor levels. 

CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 14 faculty positions, and 
a graduate student body of 110 students, 40 
of which are in the Ph.D program. Depart¬ 
mental facilities are based upon a ethernet 
local area network, connected to INTER¬ 
NET, which supports a UNIX operating sys¬ 
tem and about 40 SUN and other worksta¬ 
tions. In addition, faculty and students 
participating in the Center for Automation 
and Intelligent Systems Research have ac¬ 
cess to the Center’s computing facilities. 

Applicants should submit their curriculum 
vitae and names of at least five references to: 
Lee J. White, Chairman, Department of 
Computer Engineering and Science, 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106; INTERNET: leew@ 
alpha.ces.cwru.edu; applicants may wish to 
provide at most three reprints of their most 
important publications. 

An equal employment and affirmative ac¬ 
tion employer. 


THE AMERICAN UNIVERSITY 
IN CAIRO 
Faculty Position 

One Assistant, Associate, or Full Professor 
needed to teach, in English, undergraduate 
courses in Computer Science including 
theory of computing and design of algo¬ 
rithms. Ph.D. required. Rank, salary based 
on qualifications and experience. Two-year 
appointment (renewable) begins September 
1991. For expatriates, housing, roundtrip air 
travel, plus schooling for two children in¬ 
cluded. Write with curriculum vitae to: Dean 
George H. Gibson, The American University 
in Cairo, 866 United Nations Plaza, Suite 
517, New York, New York 10017, prefer¬ 
ably before December 15. 


110 


COMPUTER 










POLYTECHNIC UNIVERSITY 
Head, Department of 
Computer Science 

The Department of Computer Science of 
the School of Electrical Engineering and 
Computer Science invites applications for 
the position of Head of Computer Science. 

Polytechnic University is a technological 
urban university established in 1854 and 
located on three campuses in the greater 
New York area. The university has an enroll¬ 
ment of approximately 4,700 students. Be¬ 
cause of its location, there is close interaction 
with major companies in New York and New 
Jersey. The main campus is in Downtown 
Brooklyn adjacent to Brooklyn Heights, one 
of New York’s desirable residential com¬ 
munities. The other two campuses are in 
Farmingdale, Long Island, and in Haw¬ 
thorne, Westchester County. The Brooklyn 
campus is undergoing major development 
involving Metrotech, a 16-acre academic/ 
research/industrial park. As part of this pro¬ 
ject, the entire campus will be renovated; in 
particular, the Computer Science Depart¬ 
ment will be housed in a new building which 
is already under construction. 

The Department of Computer Science 
has 20 tenure-track faculty members and of¬ 
fers degree programs leading to the BS, MS 
and Ph.D. degrees. Active research is being 
carried out in the areas of software engineer¬ 
ing, algorithms, programming languages, 
compilers, computer architecture, operating 
systems network analysis and management, 
and image analysis and understanding. The 
undergraduate program is accredited by 
CSAB. In 1989 there were 158 MS degrees 
and 7 Ph.D. degrees awarded in Computer 
Science. Computer facilities include Sun 
workstations, Apollo workstations, a VAX 
780, an IBM 4381, and IBM 4341, a Gould 
9080, and AT&T 3B2/1000, two AT&T 
3B2/500s, two AT&T 3B2/400s, several 
PC labs, and an instructional laboratory. The 
campuses are fully networked. 

Applicants should have a Ph.D. degree 
and an outstanding record in Computer 
Science. Applications and nominations 
should be sent to the Chairman of the Com¬ 
mittee, Professor Theodor Tamir, Depart¬ 
ment of Electrical Engineering, Polytechnic 
University, 333 Jay Street, Brooklyn, NY 
11201. Polytechnic is an Equal Opportunity 
Employer, M/F/V/H. 


GEORGE MASON UNIVERSITY 
Faculty Positions in Computer Science 

The Department of Computer Science at 
George Mason University is seeking appli¬ 
cants for positions at two ranks: assistant 
professor and full professor. At the assistant 
professor rank we are interested in recruiting 
persons in image processing, computer 
vision, and artificial intelligence to work with 
growing efforts underway in these areas. We 
are especially interested in outstanding 
teachers and researchers in software engi¬ 
neering-artificial intelligence and parallel 
computing—image processing. At the full 
professor level we are interested in recruiting 
an established person with an international 
reputation in software systems or computer 
networking-distributed systems to lead a new 
initiative. The professor rank carries tenure. 


Visiting faculty positions may be available at all 
ranks. The nominal date of appointments 
commences September 1991. 

Candidates for these positions must have 
an earned doctorate in a relevant field, along 
with professional accomplishments that are 
appropriate in the rank sought. They should 
be interested in both teaching and developing 
a strong sponsored research program. 

The relevant research and teaching areas of 
interest in Computer Science are: artificial in¬ 
telligence, computer vision and image pro¬ 
cessing, parallel computation and distributed 
computation, and software engineering. 

There are nearly 100 faculty in SITE, and 
nearly 25 faculty in Computer Science. There 
are numerous opportunities for government 
and industrial interaction in the suburban high 
technology area, just 15 miles southwest of 
the Nation’s Capital. George Mason Univer¬ 
sity is located in Fairfax County, Virginia, near 
the outstanding scientific, cultural, and 
touristic attractions of Washington, D.C. The 
University has made a major commitment to 
establish a School of Information Technology 
and Engineering (SITE) and maintain an out¬ 
standing academic and research program in 
the Department of Computer Science. 

The Computer Science Department plans 
to move into a new building with new ad¬ 
vanced computing facilities in 1991. Present 
office systems include Sun networks, Mac net¬ 
works, and Vax networks, with research 
machines including hypercubes, symbolics 
systems, transputer systems, and NEXT 
machines. 

For full consideration please send a detailed 
resume together with the names of four refer¬ 
ences and other supporting material to Profes¬ 
sor David Rine, Chair, Recruitment Commit¬ 
tee, Department of Computer Science, 
George Mason University, Fairfax, VA 
22030, or call at (703) 323-2713 (e-mail: 
drine@gmuvax.gmu.edu). Applications are 
sought by Feb. 1, 1991, and these will receive 
first priority. AA/EOE. 


UNIVERSITY OF FLORIDA 
Computer and Information Sciences 
Department 

Applicants with strong research capability 
in one of the specialized areas and able to 
teach a variety of courses in Computer and 
Information Sciences are invited for tenure- 
track and visiting positions at all levels. Areas 
of specialization include software engineer¬ 
ing, computer vision, database systems and 
artificial intelligence. Positions are available 
starting in Spring 1991 as well as the 1991- 
92 academic year. Each applicant must have 
a doctoral degree in Computer Science or a 
related area or will complete the degree 
before the start of the faculty appointment. 

Applicants should send their resumes and 
four names and addresses to: Professor 
Randy Chow, Chairman, Faculty Search 
and Screening Committee, Computer and 
Information Sciences Department, 301 CSE, 
University of Florida, Gainesville, FL 32611; 
telephone number: (904) 392-1200, e-mail 
address: chow@cis.ufl.edu. 

Closing date: October 31, 1990 or until 
positions are filled. University of Florida is an 
Equal Opportunity/Affirmative Action Em¬ 
ployer. This faculty search will be in com¬ 
pliance with Florida’s “government in the 
Sunshine Law.” 


SENIOR ANALYST 

Senior Analyst needed to design, imple¬ 
ment, and test software packages to be used 
for production planning and scheduling for 
large manufacturing companies. Confer with 
program management to identify customer 
scheduling needs. Interface with customers 
in order to design and implement software 
that will meet their needs. Provide training 
and technical support for scheduling pro¬ 
grams. Analyze, test, and debug scheduling 
software. Evaluate software for potential 
scheduling problems. Plan and prepare tech¬ 
nical reports and instructional manuals 
relative to the operation of the program. Re¬ 
quires a Master’s degree in Operation 
Research/Computer Science or its equiva¬ 
lent. Must have at least three credit hours in 
the following: operations research, com¬ 
puter science, artificial intelligence and 
scheduling as well as LISP and C program¬ 
ming languages. 40 hour work week. 
$36,000 per year. Apply at the Texas 
Employment Commission, Dallas, Texas, or 
send resume to the Texas Employment 
Commission, TEC Building, Austin, Texas 
78778. Job Order #5424746. Ad paid for 
by an Equal Employment Opportunity 
Employer. 


CARLETON UNIVERSITY 
School of Computer Science 
Faculty Position 

Applications are invited for a tenure track 
position at the rank of Assistant or Associate 
Professor in the School of Computer Sci¬ 
ence starting July 1, 1991. The School has 
17 full-time faculty with particular research 
strengths in algorithms and complexity, in¬ 
telligent systems, object-oriented program¬ 
ming, and parallel and distributed comput¬ 
ing. Outstanding candidates with a Ph.D. in 
any area of computer science and engineer¬ 
ing will be considered. Successful candidates 
are expected to pursue an active research 
program, perform both graduate and under¬ 
graduate teaching, and supervise graduate 
students. The School offers both undergrad¬ 
uate honours programs and graduate pro¬ 
grams up to the Ph.D. level. The programs 
have restricted enrollment in order to main¬ 
tain a high quality research and teaching 
environment. Prospective faculty can look 
forward to a dynamic research environment 
in which collaboration with industry is 
encouraged. Carleton is located in Ottawa, 
the capital of Canada and a major center 
of advanced technology research and 
development. 

Salary commensurate wtih qualifications 
and experience. Send curriculum vitae and 
names of three referees to Professor Frank 
Fiala, Acting Director, School of Computer 
Science, Carleton University, Ottawa, On¬ 
tario K1S 5B6, Canada. 

Carleton University is committed to equal¬ 
ity of employment for women, aboriginal 
peoples, visible minorities, and disabled per¬ 
sons. Interested persons from these groups 
are encouraged to apply. In accordance with 
Canadian immigration requirements, this 
advertisement is directed to Canadian citi¬ 
zens and permanent residents. 

This position is subject to budgetary 
approval. 


October 1990 









UNIVERSITY OF MINNESOTA 
MINNEAPOLIS, MINNESOTA 
Department of Electrical Engineering 

The Department of Electrical Engineering 
invites applications and mominations for 
tenure track and tenured positions of all 
ranks. In addition for the 1991-92 academic 
year several visiting and temporary positions 
are available. The duties of tenure and 
tenure track faculty include the establishment 
of a sponsored research program and teach¬ 
ing at both the undergraduate and graduate 
level. Candidates with exceptional qualifica¬ 
tions in all areas of electrical engineering will 
receive due consideration. Of particular in¬ 
terest, however, are individuals whose 
specialties lie in the areas of computer ar¬ 
chitecture and digital electronics, circuits and 
VLSI design, and microelectronics, with par¬ 
ticular interests in optoelectronics, or 
micromachining. 

The Department of Electrical Engineering 
has 46 faculty members providing under¬ 
graduate and graduate education and pursu¬ 
ing research in all areas of electrical engineer¬ 
ing. The State-funded Microelectronics and 
Information Sciences Center and the Super¬ 
computer Institute at the University of Min¬ 
nesota provide opportunities for interdisci¬ 
plinary research. The Department has a 
complete integrated circuit fabrication and 
design laboratory. Faculty have direct access 
to the full range of computing facilities in¬ 
cluding supercomputers. 

The requirements for all positions include 
an earned Doctorate in an appropriate disci¬ 
pline at the time of the appointment and out¬ 
standing academic and research records. 
Rank and salary will be commensurate with 
the qualifications and experience of the 
selected candidates. Applications and nomi¬ 
nations should be sent with a resume con¬ 
taining the names of three references to: 

Professor Larry L. Kinney, 
Chairman of the Faculty 
Recruiting Committee, 
Department of Electrical Engineering, 
University of Minnesota, 

200 Union St. SE, Minneapolis, MN 
55455 

The last date for receiving applications will 
be August 30, 1991 for positions available 
September 16, 1991. Review and interviews 
may begin as early as November 15. 1990, 
and early decisions can be made on positions. 

The University of Minnesota is an equal 
opportunity educator and employer and 
specifically invites and encourages applica¬ 
tions from women and minorities. 


CASE INSTITUTE OF TECHNOLOGY 
CASE WESTERN RESERVE 
UNIVERSITY 

We invite applications for tenure track 
faculty positions at all levels. Candidates 
from all research areas will be considered, 
but the thrust research areas in the Depart¬ 
ment are VLSI systems and design automa¬ 
tion, applied artificial intelligence and logic 
programming, database design and systems, 
and software systems and design environ¬ 
ments. Candidates should have a Ph.D. in 
computer science or computer engineering 
or closely allied fields; competitive salaries 
will be offered to attract the best candidates. 


CWRU is a private university with a total 
enrollment of 8,400, of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 14 faculty positions, and 
a graduate student body of 110 students, 40 
of which are in the Ph.D. program. Depart¬ 
mental facilities are based upon an ethernet 
local area network, connected to INTER¬ 
NET, which supports a UNIX operating sys¬ 
tem and about 40 SUN and other worksta¬ 
tions. In addition, faculty and students 
participating in the Center for Automation 
and Intelligent Systems Research have ac¬ 
cess to the Center’s computing facilities. 

The Department recently acquired the 
Nord Professorship, supported by a dona¬ 
tion of over one and a half million dollars, for 
which we invite distinguished senior faculty 
applicants. This position will provide addi- 
tional funds for travel, graduate student sup¬ 
port and equipment. 

Applicants should submit their curriculum 
vitae and names of at least three references 
to: Lee J. White, Chairman, Department 
of Computer Engineering and Science, 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106; INTERNET: leew@ 
alpha.ces.cwru.edu; candidates with pre¬ 
vious academic experience may wish to pro¬ 
vide at most three reprints of their most 
important publications. 

An equal employment and affirmative ac¬ 
tion employer. 


HARVEY MUDD COLLEGE 
Senior Position in Computer Science 

Harvey Mudd College has re-opened its 
search for a senior professor of computer 
science to lead the department and help 
design a curriculum for a major in computer 
science. The successful candidate for this 
position will be able to provide leadership 
and direction both for the college’s overall 
computer science program and for the new 
major. He or she must also desire the chal¬ 
lenge and opportunity to develop a program 
which builds on the existing strengths of the 
college in science and engineering. Qualifi¬ 
cations for the position include a doctorate in 
computer science or in a related field with 
computer science experience, demonstrated 
commitment to excellence in teaching, a will¬ 
ingness and ability to participate in cur¬ 
riculum development, and significant profes¬ 
sional experience. 

Harvey Mudd College, one of the nation’s 
most selective undergraduate colleges of 
engineering and science, is a member of the 
Claremont Colleges. The college is an equal 
opportunity/affirmative action employer. 
Please send resume and names of four refer¬ 
ences to: Nathaniel Davis 
Dean of Faculty 
Harvey Mudd College 
Claremont, CA 91711 


SOFTWARE ENGINEER 

Responsible for the software engineering 
of process control systems upgrades and 
specials for paper applications for mftr. in 
Central Ohio. Analyzes system specifications 
& application processes; develops software 
scope & designs software subsystems; gen¬ 
erates programs in any required language; 
selects & applies reusable program modules 
to meet project requirements; produces test 
plans & conducts tests of functional sub¬ 
system; performs full system functional 
verification and field testing; produces pro¬ 
ject documentation & software documents 
for technical users; participates in the 
preparation of end-user sysem documenta¬ 
tion. Must have a B.S. in computer science 
and 3 years exp. in the job described or as 
systems engineer. As part of exp., must have 
1) participated (6 months) in the design and 
development of a project in object-oriented 
programming in a real-time environment, 2) 
written 2000 assembly lines on 8080/8085, 
3) field tested a software system with a 
minimum value of $1 million, 4) worked (1 
year) on a system having redundancy fea¬ 
tures, 5) designed a serial link protocol with 
the following features: frame check sum, 
acknowledge/not acknowledge. Salary: 
$42,000, 40 hrs/wk. (Mon-Fri, 8AM-5PM). 
Must have proof of legal authority to work 
permanently in U.S. Send resume in dupli¬ 
cate (no calls) to S. Holton, JO# 1260209, 
Ohio Bureau of Employment Services, P.O. 
Box 1618, Columbus, Ohio 43216. 


COMPUTER HARDWARE ENGINEER 

Computer Hardware Engineer to evaluate 
computer systems Hardware and Software; 
quality control; analyze computer systems 
problems; hardware development, plan lay¬ 
out of new system installation or modifica¬ 
tion of existing system; analyze data to deter¬ 
mine, recommended and plan layout for 
type of computer and peripheral equipment 
or modification of existing equipment and 
system, may specify power supply require¬ 
ments. Salary for a 40 hr work week, 9am- 
5pm Mon-Fri is $600.00 weekly. Applicants 
with a B.S. degree in Electrical Engineering 
and two years exp. send resumes only to Job 
Service of Florida, 701 S.W. 27th Ave., 
Room 15, Miami, Florida 33135 Ref: Job 
Order # FL 0315748. 


UNIVERSITY OF CALIFORNIA, 
SANTA CRUZ 

Computer Engineering at UC Santa Cruz 
expects to recruit for two faculty positions for 
the 1990-91 academic year: one Associate 
or Full Professor position, and one Assistant 
position. The areas of specialization have not 
been defined at this time. 

For more information please see our ad in 
next months Computer Magazine or inquire 
at the following address: Chair, Computer 
Engineering Faculty Search Committee, 
Baskin Center for Computer Engineering & 
Information Sciences, Applied Sciences 
Building, University of California, Santa 
Cruz, CA 95064. UCSC is an EEO/AA/ 
IRCA employer. (Via email to recruit@ 
saturn.ucsc.edu or recruit@ucsccrls.bitnet) 
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STANFORD UNIVERSITY 
Engineering Research Associate 
Entry Level 

Position available in wide spectrum speci¬ 
fication languages and support environ¬ 
ments for systems design and specification, 
involving design of new specification lan¬ 
guages for concurrent and time-critical 
systems, and development of application 
tools. Will take responsibility for ongoing 
projects to develop software tools supporting 
applications of specification languages to 
production of multi-processor Ada systems. 
Projects require the employee to develop 
new software tools for which there are no 
previous paradigms, to write user manuals, 
to publish papers in archival scholarly jour¬ 
nals, and to carry out integration of the new 
tools into commercially available fielded Ada 
programming environments. 

Required: Ph.D. in Computer Science or 
Electrical Engineering; knowledge of Ada 
programming constructing Ada compilers 
and realtime multi-tasking Ada systems; 
knowledge of recent developments in Speci¬ 
fication Languages, Program Verification, 
and Automated Deduction. Salary $55,000 
annum. Place of employment and inter¬ 
views: Stanford. Send this ad and a resume 
to Job *NOF 927, P.O. Box 9560, Sacra¬ 
mento, CA 95823-0560 no later than No¬ 
vember 15, 1990. 


RENSSELAER POLYTECHNIC 
INSTITUTE 
Chairman of 

Computer Science Department 

Applications and nominations are invited 
for the position of Professor and Chairman 
of the Computer Science department. Can¬ 
didates should be internationally recognized 
for their research, with an outstanding record 
of research support and strong commitment 
to excellence in teaching and service. 

The department has twenty-two faculty 
members who conduct research in parallel 
and distributed computation, database sys¬ 
tems, computer vision and image process¬ 
ing, learning algorithms, visual programming 
languages, VLSI systems, symbolic and 
numeric computation and theory of compu¬ 
tation. The department has active under¬ 
graduate and graduate programs that offer 
B.S., M.S. and Ph.D. degrees in computer 
science. There are 300 undergraduate majors 
and 118 graduate students, including 46 
Ph.D. students. The research program is 
supported by the government and major 
corporations at the level of 2 million dollars 
per year. In 1989 the department was granted 
an institutional Infrastructure award from 
NSF. Computing facilities are excellent and 
support the full range of paradigms for 
parallel computing, symbolic computation 
and image processing, e.g., MASPAR, Intel 
hypercube, Sequent, Ardent, AIS-5000, 
Symbolics, and networks of Sparc, Dec and 
Macintosh work stations. 

Various research projects are conducted 
in cooperation with other RPI departments, 
like Electrical, Computer and System Engi¬ 
neering or Applied Mathematics, and with 
Rensselaer’s interdisciplinary centers for in¬ 
teractive computer graphics, integrated elec¬ 
tronics, manufacturing productivity and ap¬ 


plied mathematics and advanced computa¬ 
tion. Our location in the Northeast is close by 
to many major computer companies, with 
many opportunities for collaboration. In par¬ 
ticular, the corporate research and develop¬ 
ment center of General Electric is located 
within ten miles of Rensselaer. There is also 
an active incubator program which helps 
Rensselaer faculty and students launch start¬ 
up companies. 

Rensselaer, the oldest technological uni¬ 
versity in the US, has been traditionally 
recognized for its excellence in teaching. This 
strong commitment to teaching has been 
most recently evidenced in the newly formed 
center for innovation in undergraduate edu¬ 
cation. Finally, the capital district region of 
New York provides an excellent living envi¬ 
ronment with many nearby recreational op¬ 
portunities and close proximity to the major 
Eastern metropolitan areas. 

Applicants should send a resume and the 
names of at least three references to: Pro¬ 
fessor Boleslaw Szymanski, Chairman of 
Search Committee, Department of Com¬ 
puter Science, Rensselaer Polytechnic In¬ 
stitute, Troy, N.Y. 12180-3590 (telephone: 
518-276-2714, email: szymansk@turing.cs. 
rpi.edu, fax: 518-276-4033). The position 
will be filled no later than July 1, 1991. 

RPI is an Affirmative Action, Equal Op¬ 
portunity Employer. 


ASTEM, KYOTO, JAPAN 
Advanced Software and Mechatronics 
Research Institute 

The newly established ASTEM, Kyoto, 
Japan, invites applications for research 
associate and senior research positions. 

Speciality areas include, but are not 
limited to, Software Engineering, Knowl¬ 
edge Base, Computer Graphics, and CAD/ 
CAM/C1M. For a research associate posi¬ 
tion, a candidate should be highly qualified 
and hold an MS in CS, EE, or related fields; 
for a senior research position a PhD is nor¬ 
mally required. 

ASTEM provides an excellent environ¬ 
ment for research in Software Engineering 
and AI with unique Japanese software and 
the state of the art workstations. 

ASTEM is located in Kyoto, the ancient 
beautiful city of Japan. 

Send resume to: Mr. A. Kamei, 

ASTEM, Kyoto Research Park, 17 
Chudoji, Minami-machi, Shimogyo, Kyoto 
600 JAPAN 
or call (213) 544-1103. 


EMPLOYMENT OPPORTUNITY 

Company needs an applicant with Master’s 
Degree in Computer Engineering and hav¬ 
ing taken courses in network, math statistics, 
system programming and communication 
systems. Will do research, develop and im¬ 
plement communication network software 
systems, and to interface computer hard¬ 
ware with communication equipment. Salary 
$33,500/year, 40 hour/week. Send your 
resume to Mrs. Jimmie Gaston, Division of 
Employment Security, 505 Washington, St. 
Louis, Missouri 63101. Re: Job *410397. 


UNIVERSITY OF CALGARY 
Assistant Professor 
Department of Computer Science 

The University of Calgary Department of 
Computer Science invites applications for an 
Assistant Professor (tenure-track) effective 
July 1, 1991. Duties include teaching at the 
undergraduate and graduate levels (PhD. 
and MSc) and maintaining an active re¬ 
search program in computer science. A re¬ 
searcher in software engineering, systems or 
computer graphics is particularly required, 
however all qualified candidates in all areas 
of core computer science are encouraged to 
apply. Research facilities include a large net¬ 
work of Sun and Apollo workstations and 
fileservers connected using FDDI running 
Unix. Requirements include a PhD in com¬ 
puter science or a related area. 

In accordance with Canadian immigration 
requirements, priority will be given to Cana¬ 
dian citizens and permanent residents of 
Canada. The University of Calgary has an 
Employment Equity Program and encour¬ 
ages applications from all qualified can¬ 
didates, including women, aboriginal peo¬ 
ple, visible minorities, and people with 
disabilities. 

Interested candidates should direct appli¬ 
cations, including a curriculum vitae, copies 
of their three most important publications, 
and the names of three references, prior to 
January 31, 1991, to: 

Dr. Jon Rokne, Head 
Department of Computer Science 
The University of Calgary 
2500 University Drive N.W. 

Calgary, Alberta, Canada 
T2N 1N4 

Telephone: (403) 220-5454 


UNIVERSITY OF EVANSVILLE 
Faculty Positions in 
Computer Science 

The Department of Electrical Engineering 
and Computer Science at the University of 
Evansville invites applications for a tenure 
track faculty position in computer science for 
the fall semester of 1991. Candidates should 
hold a Ph.D. (or a Master’s degree with at 
least four years’ experience). All specialty 
areas of computer science will be con¬ 
sidered. Salary and rank will be commensu¬ 
rate with academic background and experi¬ 
ence. The University of Evansville is an 
undergraduate teaching institution with 
2100 full-time undergraduates. Special con¬ 
sideration will be given to candidates with 
undergraduate computer science credentials 
and advanced degree work in either com¬ 
puter science or engineering. Applicants 
should be interested in helping develop 
ABET/CSAB accreditable programs. We 
encourage applications from qualified 
women and under-represented minorities. 
The University of Evansville is an equal op¬ 
portunity/affirmative action employer. 
Please send resume and three references to: 
Dr. John R. Tooley, Dean of the College of 
Engineering and Computer Science, 1800 
Lincoln Avenue, Evansville, Indiana 47722. 
Consideration of applications will begin on 
September 1, 1990, and continue until the 
position is filled. 


October 1990 
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ROYAL INSTITUTE OF 
TECHNOLOGY (KTH) 

School of Computer Science 
and Engineering 

Applications are invited for the position of 
Professor in Software Engineering, seen as 
the discipline studying methods and tools for 
the construction of large computer pro¬ 
grams. Topics of interest include require¬ 
ments specification, prototyping, program¬ 
ming, verification, testing, maintenance, and 
computer based tools. 

Duties of the new professor will also in¬ 
clude teaching at the undergraduate and 
graduate levels. 

Candidates are invited to submit their ap¬ 
plication, addressed to the Swedish govern¬ 
ment, before October 31, 1990, to the Reg¬ 
istrar, The Royal Institute of Technology 
(KTH), S-10044 Stockholm, Sweden. The 
application should include the reference 
number 797/90, a curriculum vitae and a 
description of research activities and plans. 

For futher information please contact 
Prof. Lars-Erik Thorelli, dean of the School 
of Computer Science and Engineering, 
KTH, S-10044 Stockholm, Sweden, phone 
+ 46-8-7907880, fax +46-8-247784, 
email le@tds.kth.se. 


UNIVERSITY OF NOTRE DAME 
Chairperson 

Department of Computer Science 
and Engineering 

The University of Notre Dame invites ap¬ 
plications for the Chair of the recently esta¬ 
blished Department of Computer Science 
and Engineering in the College of Engineer¬ 
ing. This position is a unique opportunity to 
provide significant input in establishing direc¬ 
tion for the initiation and growth of programs 
in this department. Persons with established 
records in education and scholarship who 
would welcome the challenge of developing 
a new department and its programs are en¬ 
couraged to apply. The faculty of the depart¬ 
ment is expected to determine the curricula 
leading to graduate and undergraduate de¬ 
grees in computer science and in computer 
engineering. 

The Department of Computer Science 
and Engineering has twelve tenure-track 
faculty positions. The Department of Elec¬ 
trical Engineering and its present graduate 
and undergraduate options of emphasis in 
computer engineering are expected to pro¬ 
vide the foundation for the programs in the 
new department. It is anticipated that the 
Department of Computer Science and Engi¬ 
neering will have close cooperative ties with 
the Department of Electrical Engineering, 
Department of Mathematics, and other aca- 

Qualified applicants are encouraged to 
submit a resume and letter of interest to: 

Dr. Panos J. Antsaklis 

Department of Electrical Engineering 

University of Notre Darrte 

Notre Dame, IN 46556 

For additional information, please contact 
the Dean’s office at (219) 239-5534. 

The University of Notre Dame invites ap¬ 
plications from all qualified persons without 
regard to sex, ethnic origin, religious prefer¬ 
ence or physical impairment. 


ACADEMIA SINICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tion in Institute of Information Science, 
Academia Sinica. Ph.D. in Computer Sci¬ 
ence or closely related fields required. 
Demonstratable research ability necessary. 
Applicants for senior positions must have 
proven research record. All fields in Com¬ 
puter Science are welcome. 

The Institute offers a good research en¬ 
vironment. No duty of teaching. Facilities in¬ 
clude a 32-node NCUBE 2 parallel super¬ 
computer, many SUN, SGI, and E&S work¬ 
stations. An easily accessible ETA-10Q 
supercomputer is in the Academia Sinica. 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica, Tai¬ 
pei, Taiwan, 11529, Republic of China. Fax: 
(001-886-2) 782-4814. 


THE UNIVERSITY OF CHICAGO 

Department of Computer Science 

Junior and Senior positions available. Our 
preference is for candidates with expertise in 
one of the areas of experimental Computer 
Science, such as Programming Languages 
or Distributed Systems, but we will consider 
exceptionally strong applicants from all 
areas. Send curriculum vitae and three let¬ 
ters of reference to: Prof. Janos Simon, 
Chairman, Department of Computer Sci¬ 
ence, The University of Chicago, 1100 E. 
58th Street, Chicago, IL 60637. Inquiries 
can be directed to chair@cs.uchicago.edu. 

The University of Chicago is an equal op¬ 
portunity/affirmative action employer. 


FLORIDA STATE UNIVERSITY 
Department of Computer Science 

The Department of Computer Science is 
seeking qualified candidates for expected 
tenure track positions. Areas of special in¬ 
terest include, but are not limited to, software 
engineering, operating system, networking, 
programming languages, computer graphics, 
database, and computer architecture. 

Our department is a young and rapidly 
growing one. It offers B.S., M.S., and Ph.D. 
degrees, and it places a very strong emphasis 
on excellence in research and teaching. 

Research facilities include a CRAY Y-MP/ 
432, a CM2 Connection Machine, an ETA- 
10, internet connections through SURANET 
and ESnet, a group SUN 3 and SUN 4 work¬ 
stations and servers, a VAX 11/780, and a 
Symbolics 3640. 

Applicants should have a Ph.D. in com¬ 
puter science or a closely related area, and a 
strong commitment to teaching and research. 

Send a resume and names of at least three 
professional references to: 

Dr. Abe Kandel, Chairman 
Department of Computer Science B-173 
Florida State University 
Tallahassee, FL 32306-4019 
Florida State University is an Equal Op¬ 
portunity Affirmative Action Employer. 


GRADUATE RESEARCH 
ASSISTANTSHIPS 

The Department of Ocean Engineering at 
Florida Atlantic University has a number of 
graduate research assistantships available to 
qualified students. Positions in the areas of 
marine structures, marine materials and cor¬ 
rosion, acoustics and vibrations, hydro¬ 
mechanics and marine vehicles will start in 
the Spring 1991 term. FAU is an Equal Op¬ 
portunity Affirmative Action Employer, and 
offers the M.S. and Ph.D. in Ocean Engi¬ 
neering. Interested students should write to 
Dr. Stanley E. Dunn, Department of Ocean 
Engineering, Florida Atlantic University, 500 
N.W. 20th Street, Boca Raton, FL 33431. 


CALIFORNIA STATE UNIVERSITY, 
FULLERTON 

Tenure-Track and Full-Time 
Lecturer Faculty Positions 
Computer Science Department 

The California State University, Fullerton 
(CSUF) seeks faculty candidates for tenure- 
track and full-time lecturer positions in the 
Computer Science (CS) Department effec¬ 
tive as of August 19, 1991. CSUF is an 
urban university located in the heart of 
Orange County. The aerospace and compu¬ 
ter industries create a professionally chal¬ 
lenging environment for computer scientists. 
The department has an enrollment of about 
1000 students and a team of 14 full-time and 
20 part-time faculty members. The depart¬ 
ment’s strong instructional programs lead to 
bachelor’s and master’s degrees as well as 
providing courses for non-majors. 

The CS Department is one of the four de¬ 
partments in the School of Engineering and 
Computer Science. The other departments 
are Civil Engineering, Electrical Engineering, 
and Mechanical Engineering Departments. 
The school has an enrollment of about 2500 
students. The school’s new building provides 
substantial laboratory resources for teaching 
and research in computer science and has 
a rich and diverse complement of computer 
hardware. 

The faculty candidates should have a doc¬ 
torate in computer science or a closely- 
related discipline. They must be prepared to 
teach a variety of courses and specialize in 
one of the following subjects: operating sys¬ 
tems and architecture, networks, database, 
or computer graphics. For promotion and/or 
tenure consideration, an excellent teaching 
record and a strong background in research 
and refereed publishing are required. 

Applicants should indicate if they are in¬ 
terested in tenure-track or full-time lecturer 
position. Qualified applicants will be selected 
from applications received before February 
1, 1991, or until the positions are filled. The 
university serves an ethnically diverse com¬ 
munity. Minorities and women are encour¬ 
aged to apply. For more information, and to 
request an application form, please contact 
Dr. Charles Mosmann, Chair, Computer 
Science Department, Room CS-522, Cali¬ 
fornia State University, Fullerton, Fullerton, 
California 92634; telephone number (714) 
773-3700. 

Affirmative Action Equal Opportunity Title 
IX Employer. 
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DISTRICT PROFESSIONAL 
SERVICES MANAGER 


District Professional Services Manager, 
Atlanta. Manage, direct, develops Profes¬ 
sional Services Department for SE District. 
Formulate Department revenue forecasting, 
budgeting, district strategy, planning/direc¬ 
tion: Liaise with corporate marketing and 
product management. Supervise 8 profes¬ 
sional employees and indirectly supervise 8 
Systems Engineers; responsible for all per¬ 
sonnel decisions. Direct pre and post sales 
system consultations. Design information 
systems specific to customer needs; plan 
system implementation. Responsible for 
long range project with major customer. 
Liaise with managers in North America, UK 
and Mexico; direct efforts with major soft¬ 
ware/hardware companies; coordinate de¬ 
velopment groups in North America and 
UK. Assess product/services and recom¬ 
mend on efficiency/profit. Assess Opera¬ 
tions strategies/objectivies. Ensure adequate 
staffing; recruit staff and assign to projects/ 
customer. BS in Science, Computer Science 
or Information Systems and 3 years experi¬ 
ence in job offered or 3 years experience as 
Manager Information Systems required. Ex¬ 
perience must include primary responsibility 
for corporate department/division with in¬ 
formation systems manufacturer and formu¬ 
lation responsibility for business plans/ 
budgetary goals. Requires experience super¬ 
vising professional information systems staff; 
must have experience in software operation 
and implementation of ICL software and 
systems. 40 hrs./wk.; 8am-5pm; $60,000/ 
yr. Apply in person or by resume to Georgia 
Department of Labor, 2972 Ask-Kay Dr., 
Smyrna, GA 30082 or to nearest Georgia 
Job Service Center. Reference Control 
#GA5439540. 


THE UNIVERSITY OF TEXAS 
AT ARLINGTON 

The Department of Computer Science 
Engineering at The University of Texas at Ar¬ 
lington invites applications for tenure-track 
or visiting faculty positions in all areas of 
computer science or computer engineering. 
Applicants with expertise relating to reliable 

cations software, object-oriented systems, 
scientific visualization, knowledge-based 
systems, or parallel processing will be given 
preference. Rank is open. An earned doc¬ 
torate or equivalent and a commitment to 
teaching and scholarly research are re¬ 
quired. Openings are expected for January 
and September 1991. Applications received 
prior to October 15, 1990 and March 1. 
1991 will receive full consideration for 
January and September openings, respec¬ 
tively. Interested persons should send a 
resume and a list of references to Bill D. 
Carroll, Professor and Chairperson, Com¬ 
puter Science Engineering Department, 
P.O. Box 19015, The University of Texas at 
Arlington, Arlington, TX 76019. Phone: 
817-273-3785. FAX 817-273-2548, Inter¬ 
net: carroll @evax. arl. utexas. edu. 

The University of Texas at Arlington is an 
Equal Opportunity Affirmative Action 
Employer. 



National University of 
Singapore 

Department of Electrical Engineering 


The Department of Electrical Engineering invites applications for teaching 
and research positions from candidates with a PhD degree in one of the fol¬ 
lowing areas: 


Computer Communications 
Computer Systems 
Image Processing/Computer Vision 


Gross annual emoluments range as follows: 

Research Fellow S$44,860 - 64,200 

Lecturer S$53,160-64,200 

Senior Lecturer S$58,680-100,310 

Associate Professor S$88,650 -122,870 

(US$1.00=S$1.81 approximately) 

The commencing salary will depend on the candidate's qualifications, expe¬ 
rience and the level of appointment offered. 


Leave and medical benefits will be provided. Depending on the type of con¬ 
tract offered, other benefits may include: provident fund benefits or an end- 
of-contract gratuity, a settling-in allowance of S$1,000 or S$2,000, subsidised 
housing at nominal rentals ranging from S$100 to S$216 p.m., education al¬ 
lowance for up to three children subject to a maximum of S$10,000 per annum 
per child, passage assistance and baggage allowance for the transportation 
of personal effects to Singapore. Staff members may undertake consultation 
work, subject to the approval of the University, and retain consultation fees 
up to a maximum of 60% of their gross annual emoluments in a calendar year. 


The Electrical Engineering Department has currently an academic staff of 51 
with 18 laboratories, all of which have excellent facilities for teaching and 
research. Its Semiconductor Laboratory has a Riber 32P Molecular Beam 
Epitaxy System and 2 liquid phase epitaxy systems for research into III-V 
compound devices, while its Microelectronics Laboratory has facilities for 
fabricating ICs in 4-micron poly-gate single metal CMOS technology. A wide 
range of computing resources are available, including numerous PCs, SUN 
Sparcstations, Microvaxes, and HP 9000 Series 300s. The University Com¬ 
puter Centre operates an IBM3081 KX2, and is acquiring a high-speed cam¬ 
pus-wide network directly linking the staff's PCs (now provided to every 
staff member) to the various computing resources, including 2 super¬ 
computers based in the nearby Science Park. A number of large-scale re¬ 
search projects are in progress, including an optical LAN joint effort with 
Singapore Telecoms and project to develop VLSI design tools jointly with 
Chartered Semiconductors. 


Application forms and further information on terms and conditions of ser¬ 
vice may be obtained from: 


The Director 
Personnel Department 
National University of Singapore 
10 Kent Ridge Crescent 
Singapore 0511 


The Director 

North America Office 

National University of Singapore 

55 East 59th Street 

New York, NY 10022 U.S.A. 

Telephone: (212)751-0331 


Enquiries on current research activities in specific areas may be sent 
through BITNET to: PERLT @ NUS3090 












BOOK REVIEWS 


Editor: Guy Johnson, Department of Information Technology, Rochester Institute of Technology, 1 Lomb Memorial Drive, Rochester, NY 14623. 


Computer Graphics 

Francis S. Hill, Jr. (Macmillan, New York, 1990, 754 pp„ $51) 


By taking an engineering approach to 
this introduction to computer graphics. 
Hill has produced a solid text for a one- 
or two-semester course on computer 
graphics concepts and techniques at the 
junior, senior, or graduate level. For a 
core course in graphics, it is definitively 
a more up-to-date alternative to such 
classics as Newman & Sproull’s Princi¬ 
ples of Interactive Computer Graphics 
(McGraw-Hill, 1979) and Foley & van 
Dam’s Fundamentals of Interactive Com¬ 
puter Graphics (Addison-Wesley, 1982). 
The book is especially noteworthy for its 
outstanding introduction to ray tracing. 

The book is targeted at fields ranging 
from computer science to the arts, but it 
is most appropriate for electrical engi¬ 
neering, computer science, physics, busi¬ 
ness, and art majors, as well as math un¬ 
dergraduates. Its lack of formal theory 
and advanced topics to back up the many 
code segments and examples might leave 
computer science or mathematics gradu¬ 
ate students wanting more. However, this 
lack makes the book accessible to gener¬ 
al scientific audiences and provides an 
excellent implementation reference for 
software engineers. Readers should have 
experience with elementary data struc¬ 
tures and Pascal, C, or Fortran, as well as 
college-level algebra, geometry, trigo¬ 
nometry, calculus, and matrix theory. 

The book’s scope is quite impressive, 
but not comprehensive. It covers the 
field from graphical hardware devices to 
advanced rendering techniques. Most of 
the book consists of basic material pre¬ 
sented intuitively, and its organization 
reminds me of the quick-and-dirty how¬ 
to books I endured during my engineer¬ 
ing years. The text is illustrated by plen¬ 
ty of examples and code segments in 
pseudo-Pascal. 

Each chapter begins with a statement 
of goals, contains many drills and pro¬ 


gramming exercises, and ends with a 
summary and more exercises. (The entire 
text has more than 440 drill exercises 
and about 180 programming problems.) 
Chapters 3-6 thoroughly examine the 
fundamentals of the field, including win¬ 
dows, viewpoints, clipping, polygon 
drawing, curves, and fractals. After this 
highly practical material, Chapter 7 re¬ 
turns to the basics of geometry to prepare 


Hill’s introduction to ray 
tracing is the most 
complete introduction in 
textbooks today. Nowhere 
else except in conference 
tutorials or monographs 
has the topic been covered 
as well. 


the reader for the later material on ray 
tracing. Hill then exhaustively describes 
patches, surfaces of revolution, quadrics, 
and superquadrics to give the reader 
some concrete examples of geometry, 
something most computer graphics texts 
don’t have. 

Hill then introduces 2D and 3D affine 
transformations, along with homoge¬ 
neous coordinates and such uncommon 
transformations as fish-eye and unit- 
circle inversion. His coverage of projec¬ 
tions is the best I have seen and includes 
a complete taxonomy of projections and 
an excellent model of 3D viewing with 
the synthetic camera. The sections on 


raster techniques and surface design are 
very accessible but not very deep; for in¬ 
stance, they omit the theory behind 
Bezier surfaces. Hill then takes the read¬ 
er through classic shading methods to 
hidden surface elimination, such as the z- 
buffer and the Warnock algorithm tech¬ 
niques. Unfortunately, he does not cover 
all HSR/HLR methods and does not men¬ 
tion any object space algorithms, which 
are the most conceptually interesting. 

It’s Chapter 18 that should bring this 
book the attention it deserves. Hill’s in¬ 
troduction to ray tracing is the most com¬ 
plete introduction in textbooks today and 
offers many examples, code segments, 
and exercises. I highly recommend the 
book to everyone frustrated by previous 
literature that left them in the dark. No¬ 
where else except in conference tutorials 
or monographs has the topic been cov¬ 
ered as well. The book’s value as a start¬ 
ing point for research is limited, though, 
since it has very few references through¬ 
out the text and lacks selected bibliogra¬ 
phies at the end of each chapter. 

The book closes with material on ad¬ 
vanced clipping algorithms and descrip¬ 
tion of several standards. However, 

Hill’s focus on fundamentals leaves sev¬ 
eral important areas unexplored, such as 
modeling, advanced rendering, special 
effects, animation, natural phenomena 
simulation, and artistic points of view. 
Most contemporary textbooks — such as 
Rogers’ Procedural Elements for Com¬ 
puter Graphics (McGraw-Hill, 1985), 
Magnenat-Thalmann and Thalmann’s 
Image Synthesis: Theory & Practice 
(Springer-Verlag, 1987), and Burger & 
Gillies’ Interactive Computer Graphics 
(Addison-Wesley, 1989) — discuss such 
topics extensively. 

A.M. Baldassarre 

University of Houston 
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Elements of Computer Music 


F. Richard Moore (Prentice Hall, Englewood Cliffs, N.J., 1990, 560 pp., $33.40) 


My ideal “book” on computer music 
would be an interactive, multimedia trea¬ 
tise in which musical examples could be 
heard as well as seen, programs could be 
run as well as listed, and the text could 
be heard as well as read. It shouldn’t be 
long before such contraptions become 
readily available. In the meantime, stu¬ 
dents of computers and music for the 
most part must settle for old-fashioned 
books. Moore’s Elements of Computer 
Music lessens one’s impatience for the 
newfangled kind. 

Moore has directed the Center for Mu¬ 
sic Experiment at the University of Cali¬ 
fornia at San Diego since 1974, and he 
has a long and varied history in the field. 
His Cmusic — an “acoustic compiler” — 
is the first general music program written 
in a language that is almost universally 
available — in this case, C. 

Moore’s book is divided into chapters 
on “digital audio,” “instruments,” 
“rooms,” and “composing.” His presenta¬ 
tion of the basic concepts and methods in 
each of these areas is cogent and is pro¬ 
fusely illustrated with Cmusic program 
examples. As needed, Moore covers the 
main points of the physics of sound, 
psychoacoustics, and digital signal pro¬ 
cessing. Each chapter ends with a num¬ 
ber of appropriate references, making the 
book a useful guide to computer music 
literature. 

Although they are sometimes peripher¬ 
al to the main text, interesting ideas and 
facts abound in this book. Moore draws 
an interesting analogy between the com¬ 


puter and the telescope (both technologi¬ 
cal artifacts offering dramatically closer 
looks at important phenomena), discuss¬ 
es Respighi’s use of gramophonic night¬ 
ingales in his 1925 Pines of Rome, ob¬ 
serves that the ultimate instrument every 
performer plays is the room in which the 
music is being heard, and examines the 
relationship of temporal elements of mu¬ 
sic to the human body’s characteristic 
periodicities. I was intrigued by the pos¬ 
sibilities of composing in virtual acoustic 
space as well as in the traditional dimen¬ 
sions of time, pitch, and timbre. 

This work is ambitious theoretically. 
Not many books on computers and music 
start their chapters with quotes from 
Schelling, Bacon, Kuhn, Plato, and the 
like. Although Moore is at his best when 
he stays close to his disciplinary home, 
his broader speculations underscore the 
humanistic and creative implications of 
music’s encounter with modem machines. 

Moore manages to maintain technical 
rigor without sacrificing readability, but 
those readers whose algebra and trigo¬ 
nometry aren’t fresh could find them¬ 
selves swamped (or forced to forego the 
extended mathematical excursions). 
There are some reassuring parenthetical 
comments (“Do not worry if all the im¬ 
plications of these formulas are not im¬ 
mediately obvious to you — that is what 
this section is about!”) and a useful ap¬ 
pendix of relevant mathematical ideas. If 
you have a basic knowledge of music, 
acoustics, programming, and mathemat¬ 
ics, you should have few problems. 


The book hardly purports to be an en¬ 
cyclopedia and does not avoid uneven¬ 
ness of coverage. It includes a refresh¬ 
ingly clear exposition of Markov chains 
and other stochastic processes, and a 
glancing but suggestive interconnection 
of fractals, power spectra, and Brownian 
motion. On the other hand, the MIDI 
standard is mentioned only once, and the 
book ends abruptly with two paragraphs 
on algorithmic composition, surely a top¬ 
ic deserving at least as much attention as 
random sieves (which get about 20 pag¬ 
es). Moore’s lucid treatment of tuning 
and the fundamental problems of orga¬ 
nizing pitch is relegated to an appendix 
(I have the feeling it was originally in¬ 
tended as a chapter), and the excellent 
chapter summaries stop short of the last 
chapter. Lastly, Moore provides a thor¬ 
ough index, but a glossary would have 
come in handy — especially for words 
like “agogic” and “aleatoric.” 

Despite these arguable flaws, Elements 
of Computer Music is a superb introduc¬ 
tion for those “interested in learning how 
to use computers to extend the bound¬ 
aries of music,” as Moore puts it. It is a 
thought-provoking and informative treat¬ 
ment of a fascinating field that will in¬ 
creasingly affect us all — even those not 
eagerly awaiting interactive audiovisual 
devices that let us do fun things like cre¬ 
ating and manipulating sonic events of 
arbitrary complexity in real time. 

Marc Lauritsen 

Harvard Law School 


Data Exchange PC/MS DOS 

Steven S. Ross (McGraw-Hill, New York, 1989, 411 pp., $27.95) 


This book is intended to explain meth¬ 
ods for exchanging files between various 
word processors, spreadsheet programs, 
or database applications to business pro¬ 
fessionals who are not computer literate. 
However, the book is too verbose for the 
material it covers. It could be half the 
size and cover the same material more 
effectively. 

Ross does a good job of describing the 
file characteristics and idiosyncrasies of 
most of the significant word processors, 
spreadsheets, and databases, including 
Wordstar, Xywrite, Volkswriter, Emacs, 
Microsoft Word, Word Perfect, Lotus, 
Symphony, Visicalc, Quattro, dBase, and 
Supercalc. However, he should have 


summarized the file characteristics in 
two or three chapters — one each for 
word processors, spreadsheets, and data¬ 
bases — instead of 14. 

Ross explains the file attributes that 
need to be changed to convert a file be¬ 
tween different word processors. The 
user can either do the conversion manu¬ 
ally (change each required attribute using 
an editor — tedious, but often the only 
feasible method), write a utility, or buy 
one. Ross includes some elementary ex¬ 
amples of how to write a file-conversion 
utility and provides a good list of exist¬ 
ing programs. He does not make any rec¬ 
ommendations, though, nor does he indi¬ 
cate if any of the utilities require the user 


to do further editing. 

The book includes a decent list of me¬ 
dia conversion programs, as well as in¬ 
formation on cables to connect different 
PC architectures, for example, IBMs and 
Macintoshes. However, Ross does not 
explain how to set baud rates, bit rates, 
stop bits, or other parameters, nor does he 
discuss how to convert DOS and Apple 
files that have different file attributes. He 
also does not give any information on 
converting between PCs and Unix, VAX/ 
VMS, or Sun systems, or on such utilities 
and drivers as Kermit and Crosstalk. 

Krishna Vallabhaneni 

Milpitas, California 


October 1990 
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Software Quality Concepts and Plans 

Robert H. Dunn (Prentice Hall, Englewood Cliffs, N.J., 1990, 296 pp„ $51.50) 


As the title implies, this book explores 
software quality. The author has collect¬ 
ed the material into five loosely assem¬ 
bled sections. I say “loosely” because the 
sections are defined more by individual 
focuses than by strict divisions. 

The first part — Chapters 1 and 2 — 
gives a “plain vanilla” overview of soft¬ 
ware quality and introduces the balance 
of the book. The second part comprises 
Chapters 3-5 and identifies three ele¬ 
ments of quality: people, technology, and 
management. In the third part, Chapters 
6 and 7 define software quality programs 
by looking at software development 
schemes and the “hooks” for ensuring 
quality. Chapter 8 is devoted to mainte¬ 
nance and its ramifications. 

The fourth part discusses quality man¬ 
agement and is the best of the book. In 
Chapter 9, Dunn restates that “software 
quality assurance is the management of a 
software quality program.” The chapter 
deals with the software quality organiza¬ 
tion, employee roles, and defect correc¬ 
tion and tracking. Chapter 10 then zeros 
in on “measurement and methods used as 
part of a quality improvement program” 
— that is, the analysis of defect data to 
identify areas in which process improve¬ 
ment is likely. 

A good share of Dunn’s audience 


might find the last section worth the price 
of the whole volume. Chapters 11-14 
present an overview of software quality 
plans and actual samples of three types of 
plans: a plan for a small project, a plan 
for a large project (based on ANSI/IEEE 
Std. 730-1984), and a plan in accordance 
with DoD-Std-2186. These should give 
almost everyone an example of a soft¬ 
ware quality plan to fit their needs. 

Dunn recognizes that some of his audi¬ 
ence will not need to read all the chap¬ 
ters, and he notes (correctly) that some 
chapters are too basic for some readers 
or too technical for others. Therefore, 
the excellent chapter summaries are a 
major strength of the book and will save 
many readers a good deal of boredom or 
confusion, depending on their experience 
level. 

I review a text by reading the whole 
book and making comments in the mar¬ 
gins for use as I write the review. This 
book’s effect on me is apparent in its very 
clean margins. There is little of note, 
positive or negative. However, I did find 
the first three sections vague, bland, and 
rambling. A true software quality neo¬ 
phyte might find the material useful as a 
general introduction to Dunn’s view of 
the topic. The experienced analyst can 
read the chapter summaries and find 


Computers and Engineering Management 

Thomas F. Wheeler (McGraw-Hill, New York, 1989, 369 pp., $46.50) 


Engineering managers need a variety 
of information to help them make deci¬ 
sions about computer systems implemen¬ 
tation. This book attempts to bring to¬ 
gether at least some of that information. 
Unfortunately, it falls far short, resulting 
in a rather disappointing and common¬ 
place collection of computer history, in¬ 
sights, and predictions. 

The book is targeted at the mechanical 
or electronic engineering manager with a 
limited knowledge of computers and 
computer applications, but it fails to 
meet this audience’s major needs. Also, 
its format makes it difficult to get de¬ 
tailed information or insights on specific 
topics. Wheeler’s discussions often ram¬ 
ble, making it seem that he’s forcing his 
personal experiences into the text at the 


expense of flow. 

Although a fair number of figures and 
illustrations are scattered through the 
text, they do little to support or enhance 
it. The typical manager would find a 
greater number of tables and checklists 
more useful. Also, the single bibliogra¬ 
phy at the end contains few references to 
outside articles, papers, or books, making 
it difficult to find additional reading on 
specific topics. 

Wheeler sometimes sacrifices accura¬ 
cy for simplicity and generality. I noted 
several technical inaccuracies and omis¬ 
sions. For example, Wheeler defines 
“EPROMs” as an acronym for “electron¬ 
ic PROMs.” Also, his discussion of hu¬ 
man-interface input devices omits light 
pens and trackballs while devoting an en- 


pointers to the occasional, hidden bits of 
wisdom. 

The presentation in the first part is ill 
focused and refers often to other sections 
of the text. I also found that my frequent 
need to refer to a dictionary interrupted 
my train of thought. I like to think I have 
a rather robust vocabulary, but words 
like “cachet,” “recondite,” “concomi¬ 
tant,” “ontogeny,” “anthropocentric,” 
“locution,” “iconoclasm,” “tocsin,” 
“verisimilitude,” “sobriquet,” and “pal¬ 
impsest” seem better suited to a spelling 
bee than to a software quality text. 

As a reward for fighting through the 
early chapters, Dunn offers the reader 
excellent reference lists at the end of 
each chapter, providing a wonderfully 
broad spectrum of current software quali¬ 
ty literature. 

If you are looking for a good book on 
software quality, I recommend Dunn and 
Ullman’s Quality Assurance for Comput¬ 
er Software (McGraw-Hill, 1982). But if 
you need to see samples of software 
quality plans, or if you want insights into 
improving software processes, Software 
Quality Concepts and Plans is the book 
to buy. 

John W. Horch 

The Horch Company 


tire paragraph to the problems of the 
IBM PC Jr. keyboard. 

In several places, Wheeler also pre¬ 
sents statistics without reference to sup¬ 
porting studies or papers. Several state¬ 
ments presented as fact are actually 
either opinions or unsubstantiated asser¬ 
tions. 

This book will serve as neither a refer¬ 
ence book nor a source book. It does not 
serve the needs of either computer-illiter¬ 
ate or -literate managers. I can only rec¬ 
ommend it to readers interested in 
Wheeler’s insights on computer history 
or his personal prophecies on the future 
of computing. 

James B. McClanahan 

Public Service of Oklahoma 
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Three New 
Journals from 
Academic 
Press 


Computer Vision, Graphics, and Image Processing 

is expanding into two publications in 1991: 


Editors-in-Chief 
Norman Badler 

University of Pennsylvania, 
Philadelphia 

Rama Chellappa 

University of Southern 
California, Los Angeles 


Volume 53 (1991), 6 issues 


CVGIP: Graphical Models and Image Processing 

Area Editors: Brian A. Barsky, Gabor Herman, R.L. Kashyap, Nelson Max, 
Arun N. Netravali, Franco P. Preparata, Aristides A. Requicha, 

Demitri Terzopoulos, John W. Woods 
CVGIP: Graphical Models and Image Processing focuses on the synthesis 
methods and computational models underlying computer-generated or 
-processed imagery. 

ISSN 1049-9652 In the U.S.A. and Canada: $200.00 All other countries: $237.00 


Sample copies and privileged 
personal rates are available 
upon request. 

For more information, please 
write or call: 


ACADEMIC 
PRESS, INC. 

Journal Promotion 
Department 
1250 Sixth Avenue 
San Diego, CA 
92101, U.S.A. 

(619) 699-6742 

All prices are in U.S. dollars 
and are subject to change 
without notice. 


Editor-In-Chief CVGIP: Image Understanding 

Linda G. Shapiro /\ rea Editors: Ruzena K. Bajcsy, Larry S. Davis, Herbert Freeman, 

Washington, Seattle Robert M. Haralick, Thomas S. Huang, Ramesh Jain, Edward Riseman, 

Azriel Rosenfeld, Hanan Samet, Steven L. Tanimoto 

The central focus of this journal is the computer analysis of pictorial 
information. CVGIP: Image Understanding publishes papers covering all 
aspects of image analysis from the low-level, iconic processes of early vision 
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Preliminary CALL for PAPERS 



Sixth Annual ACM Conference on 


Object-Oriented Programming 
Systems, Languages, and Applications 

6-11 October 1991, Phoenix, Arizona 


Program Committee 

Alan Snyder, HP Labs (chair) 
Grady Booch, Rational 
Luca Cardelli, DEC SRC 
Pierre Cointe, Rank Xerox 
William Cook, HP Labs 
Peter Deutsch, ParcPlace Systems 
Gail Kaiser, Columbia U. 

Henry Levy, U. Washington 
Henry Lieberman, MIT 
Mark Linton, Silicon Graphics 
Ole Lehrmann Madsen, Aarhus U. 
Ron Morrison, U. St. Andrews 
Eliot Moss, U. Massachusetts 
Mayer Schwartz, Tektronix 
Guy Steele, Thinking Machines 
Jacob Stein, Servio Corporation 
Dave Thomas, Object Technology 
Mario Tokoro, Keio U./Sony CSL 
Chris Tomlinson, MCC 
Dionysios Tsichritzis, U. Geneva 
Jeannette Wing, CMU 
Rebecca Wirfs r Brock, Tektronix 
Aki Yonezawa, U. Tokyo 

Program Chair 

Alan Snyder 

OOPSLA 91 Program Chair 
Hewlett-Packard Laboratories 
(1501 Page Mill Road) 

P.O. Box 10490 

Palo Alto CA 94303-0969 

+1-415-857-8764 

oopsla91@hplabs.hp.com 

Conference Chair 

John Richards 

OOPSLA 91 Conference Chair 
IBM Research Center 
P.O. Box 704 

Yorktown Heights NY 10598 

+1-914-784-7731 

oopsla91@ibm.com 



Object technology is influencing many areas of computer technology, including 
programming languages, software engineering, user interfaces, databases, 
distributed systems, and OSI network management. The availability of practical 
support for applying object technology is encouraging its use in real-world software 
development. 

The annual OOPSLA conference is the premier forum bringing together 
researchers, developers, and practitioners to share ideas and experiences related 
to object technology. Areas of interest include: language design and 
implementation, tools and environments, components and frameworks, principles 
and theory, concurrent and distributed systems, methods and processes, 
databases and persistence. 


Papers 

The conference will include both invited and contrib¬ 
uted papers. Authors are encouraged to submit high 
quality papers describing relevant research or experi¬ 
ence. Research papers should describe work whose 
purpose is to advance the state of the art of object 
technology. Experience papers should describe 
work in which object technology has been applied for 
some purpose. The program committee will evaluate 
each paper on its relevance, clarity, correctness, orig¬ 
inality, and significance. Special consideration will 
be given to promising experience papers. Papers must 
not be under consideration elsewhere (or published) in 
the same or similar form. Do not submit multiple 
papers describing essentially the same work. 

Authors should send six copies of the full paper, in 
English, to the program chair to be received no later 
than 1 March 1991. Papers must be limited to 18 
pages, typed double spaced or typeset 10-point on 16- 
point spacing. A separate cover sheet must contain 
contact information (contact name, postal address, 
and phone number), a 100-word abstract, and indicate 
the paper category (research or experience). Submis¬ 
sions failing to meet these conditions will be rejected. 

Authors will be notified of acceptance or rejection by 
20 May 1991. Accepted papers prepared on special 
forms are due 20 July 1991. Authors of accepted 
papers are expected to sign an ACM copyright release 
form and present the paper at the conference. Pro¬ 
ceedings will be distributed at the conference and via 
SIGPLAN Notices and will be available from ACM 
Press. Outstanding papers may be considered for a 
special issue of a journal. Awards will be given to the 
best paper in each category. 

Guidelines for authors will be published in the Fall 
1990 issue of OOP Messenger , or can be obtained 
from the program chair. 


Experience Reports 

Space will be made available in a separate track for 
short presentations of unrefereed reports describing 
practical experience applying object technology to 
real-world, product-quality software development. 
Prospective speakers should submit a 1-2 page de¬ 
scription of the project scope and status and the spe¬ 
cific points to be covered in the presentation to the 
program chair by 1 April 1991. Selection will be 
based on relevance and potential interest. Summaries 
will be collected after the conference for publication 
in OOP Messenger. 

Other Contributions 

For information on tutorials, panels, workshops, 
demos, and vendor exhibits, see the Call for Participa¬ 
tion, which will be available in October at the 1990 
conference or from the conference chair. 


Important Dates 

1 March 1991 

Papers due 
1 April 1991 

Experience reports due 
20 May 1991 

Acceptance notification 
20 July 1991 

Camera-ready papers due 


Papers due 1 March 1991 
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For more information, including 
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